CN113067838B

CN113067838B - Cross-chain interaction method and device

Info

Publication number: CN113067838B
Application number: CN202110611533.3A
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: 2021-09-24
Anticipated expiration: 2041-06-02
Also published as: CN113067838A

Abstract

One or more embodiments of the present specification provide a cross-chain interaction method and apparatus. The method comprises the following steps: at least one source node in a source block chain network initiates a cross-chain request to a destination block chain network so that each destination node in the destination block chain network obtains the cross-chain request respectively; each source node acquires a cross-chain message returned by each destination node in response to the cross-chain request; each source node generates a block chain transaction according to the acquired cross-chain message and submits the generated block chain transaction to the source block chain network; each source node respectively executes the same blockchain transaction in a plurality of blockchain transactions which are commonly identified.

Description

Cross-chain interaction method and device

Technical Field

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

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Nodes in the blockchain network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update 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 blockchain subnets can be further established on the basis of blockchain main networks.

However, there may be a need for cross-chain interaction between different blockchain networks, so that a node in the source blockchain network can initiate an interaction request to the destination blockchain network. However, since different nodes in the source blockchain network may receive multiple blockchain messages returned by different nodes in the destination blockchain subnet, how to ensure that each node in the source blockchain network obtains a consistent processing result after processing the cross-chain message returned by the destination blockchain network is an urgent problem to be solved in the cross-chain interaction process.

Disclosure of Invention

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

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, there is provided a cross-chain interaction method, including:

at least one source node in a source block chain network initiates a cross-chain request to a destination block chain network so that each destination node in the destination block chain network obtains the cross-chain request respectively;

each source node acquires a cross-chain message returned by each destination node in response to the cross-chain request;

each source node generates a block chain transaction according to the acquired cross-chain message and submits the generated block chain transaction to the source block chain network;

each source node respectively executes the same blockchain transaction in a plurality of blockchain transactions which are commonly identified.

According to a second aspect of one or more embodiments of the present specification, there is provided a cross-chain interaction apparatus, where a request initiating unit is configured to enable at least one source node in a source blockchain network to initiate a cross-chain request to a destination blockchain network, so that each destination node in the destination blockchain network obtains the cross-chain request respectively;

a message receiving unit, which enables each source node to obtain the chain-crossing message returned by each destination node in response to the chain-crossing request;

the transaction submitting unit is used for enabling each source node to generate block chain transactions respectively according to the acquired cross-chain messages and submitting the generated block chain transactions to the source block chain network respectively;

and the transaction execution unit enables each source node to execute the same blockchain transaction in the plurality of commonly-identified blockchain transactions respectively.

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

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 according to any one of the first aspect.

Drawings

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

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

FIG. 3 is a schematic diagram of creating and invoking an intelligent contract according to an exemplary embodiment.

Fig. 4 is a schematic diagram of building a blockchain subnet based on a blockchain master network according to an exemplary embodiment.

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

FIG. 6 is a flowchart of a method for cross-chain interaction 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 in an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent 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 certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the network and perform related operations. Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.

Whether public, private, or alliance, may provide the functionality of an intelligent contract. An intelligent contract on a blockchain is a contract that can be executed on a blockchain system triggered by a transaction. An intelligent contract may be defined in the form of code.

Taking the ethernet as an example, the support user creates and invokes some complex logic in the ethernet network, which is the biggest challenge of ethernet to distinguish from bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, what the virtual machine directly runs is virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"). The intelligent contracts deployed on the blockchain may be in the form of bytecodes.

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

As shown in fig. 2, still taking an ethernet house as an example, after Bob sends a transaction for invoking an intelligent contract to the ethernet house network, the EVM of a certain node may execute the transaction and generate a corresponding contract instance. The from field of the transaction in FIG. 2 is the address of the account of the initiator of the transaction (i.e., Bob), the "0 x6f8ae93 …" in the to field represents the address of the smart contract being invoked, and the value field is the value in EtherFang that is kept in the data field of the transaction as the method and parameters for invoking the smart contract. After invoking the smart contract, the value of balance may change. Subsequently, a client can view the current value of balance 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, and all execution records and data are stored on the blockchain, so that after the transaction is completed, transaction certificates which cannot be tampered and cannot be lost are stored on the blockchain.

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

It should be noted that, in addition to the creation of the smart contracts by the users, the smart contracts may also be set by the system in the creation block. Such contracts are generally referred to as foundational contracts. In general, the data structure, parameters, attributes and methods of some blockchain networks may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply referred to as a system contract). In addition to EVM in the ethernet, different blockchain networks may employ various virtual machines, which is not limited herein.

After executing a transaction that invokes a 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 contract execution results may be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in the receipt. The message mechanism can implement message passing through events in the receipt to trigger the blockchain node to execute corresponding processing. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above example, the number of events may be one or more; wherein, each event respectively comprises fields of a subject (topic) and data (data). The tile chain node may perform the preset process by listening to topic of the event, in case that predefined topic is listened to, 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, it is equivalent to that there is a client with a monitoring function at a monitoring party (e.g. a user with a monitoring requirement), for example, an SDK or the like for implementing the monitoring function is run on the client, and the client monitors events generated by the blockchain node, and the blockchain node only needs to generate a receipt normally. The passage of transaction information may be accomplished in other ways than through the event mechanism described above. For example, the monitoring code can be embedded in a blockchain platform code running at blockchain nodes, so that the monitoring code can monitor one or more data of transaction content of blockchain transactions, contract states of intelligent contracts, receipts generated by contracts and the like, and send the monitored data to a predefined monitoring party. Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in the development process, or may be embedded by the monitoring party based on the own requirement, which is not limited in this specification.

The blockchain technology is different from the traditional technology in one of decentralization characteristics, namely accounting is performed on each node, or distributed accounting is performed, and the traditional centralized accounting is not performed. To be a difficult-to-defeat, open, non-falsifiable data record decentralized honest and trusted system, the blockchain system needs to be secure, unambiguous, and irreversible in the shortest possible time for distributed data records. In different types of blockchain networks, in order to keep the ledger consistent among the nodes recording the ledger, a consensus algorithm is generally adopted to ensure that the consensus mechanism is the aforementioned mechanism. For example, a common mechanism of block granularity can be implemented between block nodes, such as after a node (e.g., a unique node) generates a block, if the generated block is recognized by other nodes, other nodes record the same block. For another example, a common mechanism of transaction granularity may be implemented between the blockchain nodes, such as after a node (e.g., a unique node) acquires a blockchain transaction, if the blockchain transaction is approved by other nodes, each node that approves the blockchain transaction may add the blockchain transaction to the latest block maintained by itself, and finally, each node may be ensured to generate the same latest block. The consensus mechanism is a mechanism for the blockchain node to achieve a global consensus on the block information (or called blockdata), which can ensure that the latest block is accurately added to the blockchain. The current mainstream consensus mechanisms include: proof of Work (POW), Proof of stock (POS), Proof of commission rights (DPOS), Practical Byzantine Fault Tolerance (PBFT) algorithm, HoneyBadgerBFT algorithm, etc.

Due to the decentralized characteristic of the blockchain network, all blockchain nodes in the blockchain network can maintain the same blockchain data, and the special requirements of part of nodes cannot be met. Taking a federation chain as an example, all federation members (i.e., node members in a federation) may form a blockchain network, and all federation members respectively have corresponding blockchain nodes in the blockchain network, and may obtain all transactions and related data occurring on the blockchain network through the corresponding blockchain nodes. In some cases, however, there may be some security-required transactions that some coalition members wish to complete, which may both wish to be able to verify on the blockchain or to take advantage of other advantages of blockchain technology, and avoid other coalition members from viewing the transactions and associated data. Although the federating members can additionally build a new blockchain network in a manner similar to the blockchain network including all federating members described above, the new blockchain network is built from scratch, which consumes a lot of resources and is time-consuming in both the building process and the post-building configuration process. The demand between the members of the federation is often temporary or has a certain timeliness, so that the newly-built blockchain network can quickly lose significance due to the disappearance of the demand, thereby further increasing the link establishment cost of the blockchain network. The demands among the federation members often change, and the federation members corresponding to each demand often differ, so that a new blockchain network may need to be established whenever a change occurs in a federation member, thereby causing a great waste of resources and time.

For this purpose, the established blockchain network may be used as a blockchain master network, and a blockchain sub-network may be established on the basis of the blockchain master network. Then, in a federation chain scenario such as that described above, federation members can build the required blockchain subnets on a blockchain master basis based on their own needs, already participating in the blockchain master. Because the block chain sub-networks are established on the basis of the block chain main network, compared with the process of completely and independently establishing a block chain network, the block chain sub-networks are greatly reduced in consumed resources, required time consumption and the like, and are extremely high in flexibility.

The process of quickly establishing the block chain sub-network based on the block chain main network comprises the following steps: each main network node in the block chain main network respectively acquires transactions for establishing a block chain sub-network, wherein the transactions comprise 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 block chain main network executes the transaction respectively; when the first main network node belongs to the node member indicated by the configuration information, the node device 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 establishing the blockchain sub-network can be initiated by an administrator of the blockchain main network, that is, the administrator is only allowed to establish the blockchain sub-network on the basis of the blockchain main network, and the establishment permission of the blockchain sub-network is prevented from being opened to a common user, so that the security problem caused by the establishment permission can be prevented. In some cases, a common user of the blockchain main network may also be allowed to initiate a transaction for building the blockchain sub-network, so as to meet networking requirements of the common user, and the common user can still quickly build the blockchain sub-network under the condition that an administrator is not convenient to initiate the transaction.

For example, as shown in fig. 4, the main network of the blockchain is subnet0, and the subnet0 includes blockchain link points nodeA, nodeB, nodeC, nodeD, and nodeE. Assume nodeA, nodeB, nodeC, and nodeD wish to build a blockchain subnet: if nodeA is an administrator and only allows the administrator to initiate a transaction to build a blockchain subnet, the transaction to build the blockchain subnet can be initiated by nodeA to subnet 0; if the nodeb is an administrator and only the administrator is allowed to initiate a transaction for building the blockchain subnet, nodeb a to nodeb d need to make a request to nodeb, so that nodeb initiates the transaction for building the blockchain subnet to subnet 0; if the node E is an administrator but allows a common user to initiate the transaction of building the blockchain sub-network, the node A-node E can initiate the transaction of building the blockchain sub-network to the subnet 0. Of course, the blockchain link point initiating the transaction for building the blockchain subnet does not necessarily participate in the built blockchain subnet, regardless of the administrator or the general user, for example, although the blockchain subnet is finally built by nodeA, nodeB, nodeC and nodeD, the transaction for building the blockchain subnet may be initiated by nodeE to subnet0, but the transaction for building the blockchain subnet is not necessarily initiated by nodeA to nodeD.

When the blockchain sub-network is constructed on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain sub-network and the blockchain main network. For example, when a blockchain subnet1 is established on the subnet0 shown in fig. 4, it can be considered that the subnet0 is at the first layer, the subnet1 is at the second layer, the subnet0 is the parent network of the subnet1, and the subnet1 is the subnet 0. And the blockchain sub-network may also constitute a corresponding blockchain sub-network, for example, another blockchain sub-network bnet3 may be further constituted on the basis of the sub-net 1 in fig. 4, at this time, it may be considered that the sub-net is in the third layer, the sub-net 1 is the parent network corresponding to the sub-net 3, the sub-net 3 is the subnet of the sub-net 1, and the sub-net 3 is the grandchild network of the sub-net 0, similarly, the sub-net 3 may still newly constitute the blockchain sub-network on the basis thereof, so that such a multi-level tree structure is formed between the blockchain networks, and in this specification, any blockchain network is managed by its corresponding parent network, that is, managed by the blockchain network constituting any blockchain network of the blockchain network, so that in the blockchain sub-network as shown in fig. 4, the main level of the blockchain is the root network, and each blockchain sub-network is the corresponding tree node sub-chain sub-network of the other blockchain sub-network, and its corresponding system is represented by any blockchain sub-chain sub-network of the blockchain system, as a specific example, when the block chain master network is a bottom layer block chain network, the block chain master network is managed by the block chain master network itself. The block chain master network in this specification may be a bottom layer block chain network, where the bottom layer block chain network refers to a block chain sub-network that is not established on the basis of other block chain networks, and therefore there is no other block chain network except the block chain master network and the block chain master network can manage the block chain master network, for example, the subnet0 in fig. 4 may be considered as a block chain master network belonging to a bottom layer block chain network type, and the subnet0 manages the subnet0 itself, and of course, the block chain master network may also be a sub-network of another block chain network, which is not limited in this specification. The block chain network tree system realizes layer-by-layer management by managing the corresponding child nodes through the father nodes, reduces the management pressure of the block chain main network, and simultaneously avoids exposing subnet information of an upper network to a lower network, thereby realizing the secret management of networks at all levels.

After the transaction for establishing the blockchain sub-network is sent to the blockchain main network, the consensus nodes in the blockchain main network perform consensus, and after the consensus is passed, each main network node executes the transaction to complete establishment of the blockchain sub-network. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above, and is not limited by the present specification.

The configuration information is included in the transaction of the block chain sub-network, and the configuration information can be used for configuring the block chain sub-network, so that the block chain sub-network meets networking requirements. For example, by including the identity information of the node members in the configuration information, it is possible to specify which blockchain nodes the constructed blockchain subnet includes.

The identity information of the node member may include a public key of the node, or other information capable of representing the node identity, such as a node ID, which is not limited in this specification. Taking a public key as an example, each blockchain node has one or more corresponding sets of public-private key pairs, and the private key is held by the blockchain node and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Therefore, for blockchain nodes that are desired to be node members of a blockchain subnet, the public keys of these blockchain nodes can be added to the transaction of the building blockchain subnet as the identity information of 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 the blockchain subnet is established, the first master network node does not directly join the blockchain subnet to become a node member of the blockchain subnet, but the first subnet node needs to be generated by the node device for deploying the first master network node and becomes a node member of the blockchain subnet. The first main network node and the first sub-network node correspond to the same blockchain member, for example, correspond to the same alliance chain member in an 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 the transaction of the blockchain main network and the blockchain sub-network respectively; moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the first main network node and the blocks generated by the first sub-network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node device, so that mutual isolation between the storages used by the first main network node and the first sub-network node respectively is realized, and thus, data generated by the blockchain sub-network can only be synchronized among the node members of the blockchain sub-network, so that the blockchain members only participating in the blockchain main network cannot obtain the data generated by the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial blockchain members (namely, the blockchain members participating in the blockchain sub-network) are met.

It can be seen that the first master network node and the first sub-network node are logically divided block chain link points, and from the perspective of physical devices, the node devices which are equivalent to the first master network node and the first sub-network node are deployed to participate in both the block chain master network and the block chain sub-network. Since the blockchain main network and the blockchain sub-network are independent from each other, so that the identity systems of the two blockchain networks are also independent from each other, even though the first main network node and the first sub-network node may adopt the same public key, the first main network node and the first sub-network node should be regarded as different blockchain nodes. For example, in fig. 4, the nodeA in subnet0 corresponds to a first master network node, and the node device deploying the nodeA generates nodeA1 belonging to subnet1, and the nodeA1 corresponds to a first sub-network node. It can be seen that, since the identity systems are independent of each other, even if the public key adopted by the first subnet node is different from that of the first master network node, the implementation of the solution in this specification is not affected.

Of course, the node members of the blockchain sub-network are not necessarily only part of the node members of the blockchain main network. In some cases, the node members of the blockchain subnet may be completely consistent with the node members of the blockchain main network, and at this time, all the blockchain members may obtain data on the blockchain main network and the blockchain subnet, but data generated by the blockchain main network and the blockchain subnet may still be isolated from each other, for example, one type of service may be implemented on the blockchain main network, and another type of service may be implemented on the blockchain subnet, 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 identifier of the blockchain subnet, the identity information of an administrator of the blockchain subnet, the attribute configuration for the blockchain platform code, and the like, which are not limited in this specification. The network identifier is used to uniquely characterize the blockchain subnet, and thus the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets established on the blockchain main network. Identity information of an administrator of the blockchain subnet, such as a public key of a node member as 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 building the blockchain subnet by using the blockchain master network is that since the first master network node is already deployed on the node device generating the first subnet node, the blockchain platform code used by the first master network node can be multiplexed on the first subnet node, so that repeated deployment of the blockchain platform code is avoided, and the building efficiency of the blockchain subnet is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may reuse the attribute configuration adopted on the first master network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may adopt the attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited by the attribute configuration of the first main network node and is not related to the first main network node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

The transactions that make up the blockchain subnet include transactions that invoke contracts. The address of the invoked smart contract, the method invoked and the incoming parameters may be specified in the transaction. For example, the contract invoked may be the aforementioned startup contract or system contract, the method invoked may be a method that builds 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

the from field is information of the initiator of the transaction, such as administeror indicating that the initiator is an Administrator; the to field is the address of the intelligent contract being called, for example, the intelligent 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 in the Subnet contract to build the blockchain Subnet may be AddSubnet (string), and string is a parameter in the AddSubnet () method, and the value of the parameter is represented by the aforementioned example, which is specifically the aforementioned configuration information.

Take the example that nodes nodeA-nodeS on Subnet0 execute a transaction that invokes the AddSubnet () method in the Subnet contract. After the transaction passes the consensus, nodeA-nodeE respectively execute the AddSubnet () method and transmit configuration information to obtain corresponding execution results.

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

Event：

[topic:other][data]

[topic:subnet][data]

......

then, when the nodeA-nodeE monitors the 1 st event, the event is determined to be irrelevant to the AddSubnet () method because the contained topic content is other; and when the 2 nd event is monitored by the nodeA to nodeE, determining that the event is related to the AddSubnet () method because the contained topic content is subnet, and further reading a data field corresponding to the event, wherein the data field comprises 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；

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

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

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

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

}

where subnet1 is the network identification of the blockchain subnet that one wishes to create. Each blockchain link point in the blockchain master network may record network identifiers 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 the Subnet contract, for example, and may specifically correspond to values of one or more contract states included in the Subnet contract. Then, nodeA-nodeE can determine whether the subnet1 already exists according to the recorded network identifiers of all the created subnet block chains; if not, subnet1 is the new blockchain subnet that needs to be created currently, and if so, subnet1 is already present.

In addition to the network identifier of the new blockchain subnet that is desired to be created, a predefined new network identifier may be used, which indicates that the corresponding networking event is used to create the new blockchain subnet. For example, the subnet1 may be replaced by newsbnet, where newsbnet is a predefined new network identifier, and when the nodeA to nodeE recognize that the data field includes newsbnet, it may be determined that an event including newsbnet is a networking event and a new blockchain subnet needs to be created.

Besides the network identification subnet1, the data field also contains the identity information of each node member. The node device deploying the first master network node may monitor the generated receipt, and obtain, by the node device deploying the first master network node, configuration information or an innovation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first master network node belongs to the node member. For example, when determining that subnet1 is a blockchain subnet that needs to be newly built, nodeA to nodeE further identify the identity information of the node members included in the data field to determine their own processing methods. For example, the nodeA to nodeD may find that the data field includes identity information such as their own public key, IP address, and port number, and assume that nodeA to nodeD are respectively deployed on node devices 1 to 4, taking nodeA and node device 1 as an example: the nodeA triggers the node device 1, so that the node device 1 obtains the configuration information from the data field based on the message mechanism and generates a created block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created block, so as to become a subnet node of subnet 1; similarly, nodeB will trigger NodeB1 to be generated by node device 2, nodeC will trigger NodeC1 to be generated by node device 3, and nodeD will trigger NodeD1 to be generated by node device 4. And the nodeE finds that the identity information contained in the data field is not matched with the nodeE, and if the nodeE is deployed on the node device 5, the node device 5 does not generate a 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 master network node and the first subnet node do not necessarily adopt the same identity information. Therefore, in the above embodiment, the data field may include the identity information previously generated for nodeA 1-nodeD 1, and is different from the identity information of nodeA-nodeD. Still taking nodeA as an example, if identity information of nodeA1 is found in the data field, nodeA triggers node device 1 to generate a birth block, deploy nodeA1, and load the birth block by nodeA 1; the nodeB-nodeD processing modes are similar, and are not described in detail here.

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

In this specification, the transaction for creating the blockchain subnet may not be a transaction for calling an intelligent contract, so that the blockchain network that does not support the intelligent contract may also implement the technical solution of this specification, thereby quickly creating the blockchain subnet on the basis of the blockchain main network. For example, a group network transaction type identifier may be predefined, and when a transaction includes the group network transaction type identifier, it indicates that the transaction is used for building a new blockchain subnet, that is, the transaction is a transaction for building a blockchain subnet. The blockchain platform code may include related processing logic for constructing a blockchain sub-network, so that when a first master network node running the blockchain platform code performs a transaction, if the transaction is found to include the networking transaction type identifier and the first master network node belongs to a node member indicated by configuration information in the transaction, a node device deploying the first master network node may be triggered to generate an innovation block including the configuration information and start the first sub-network node based on the processing logic, and the innovation block is loaded by the first sub-network node to form the blockchain node in the blockchain sub-network.

The node device is equivalent to deploying a blockchain node on the node device by pulling up a process and creating an instance in the process, and running blockchain platform code by the instance. For the first master network node, a first instance is created by the node device in the above process and formed by the first instance running blockchain platform code. Similarly, for the first subnet node, a second instance different from the first instance is created by the node device in the above process, and is formed by the second instance running the blockchain platform code. When the first instance and the second instance are located in the same process, the deployment difficulty of the first subnet node can be reduced and the deployment efficiency can be improved because cross-process interaction is not involved; of course, the second instance may be in a different process on the node device than the first instance, and this specification does not limit this. In fact, each block link point deployed on any node device referred to in the embodiments of this specification is a different block chain instance running on any node device, blocks generated by each block link point deployed on any node device are respectively stored in different storages (for example, a database) on any node device, and the storages used by each block link point deployed on any node device are isolated from each other.

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 4 as an example, the subnet0 originally includes nodeA to nodeE, and can construct subnet1 on the basis of subnet0, where subnet1 includes nodeA1 to nodeD1, and nodeA1, nodeB and nodeB1, nodeC and nodeC1, and nodeD1 are respectively disposed on the same node device. Similarly, a subnet2 or more block chain subnets can be constructed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2, and nodeE2, and nodeA1, nodeA2, nodeB1, nodeB2, nodeC1, nodeD1, and nodeE2 are respectively deployed on the same node device. And, subnet1, subnet2, etc. may be used as a blockchain main network, and a blockchain subnet is further constructed on the basis, for example, a blockchain subnet3 is constructed on the basis of subnet1, the process is similar to the construction of subnet1 or subnet2, only the blockchain is replaced by a main blockchain subnet1, which is not described herein, and finally, the 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.

The cross-chain interaction requirement can exist between different blockchain main networks or between different blockchain sub-networks established in the mode. However, because there are usually a plurality of source blockchain nodes initiating a cross-chain interaction request and a plurality of destination blockchain nodes returning a message in response to the cross-chain request, different nodes in the source blockchain network may receive a plurality of blockchain messages returned by different nodes in the destination blockchain subnet, and thus how to ensure consistency of messages returned by the target blockchain network processed by each node in the source blockchain network is an urgent problem to be solved in the cross-chain interaction process.

In order to solve the problem, the present specification provides a cross-chain interaction method, in which a source node in a source blockchain network generates a blockchain transaction according to a plurality of cross-chain messages received by the source node in a destination blockchain network and returned by the destination node in the destination blockchain network, and then each source node executes the same blockchain transaction, thereby effectively ensuring consistency of messages returned by the destination blockchain network processed by each source node.

The cross-chain interaction scheme of the present specification will first be briefly described in conjunction with fig. 5, which corresponds to fig. 4. Referring to fig. 5, fig. 5 is a schematic diagram of a cross-chain 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 implementing cross-chain interaction based on subnet0 for subnet1 and subnet 2.

As shown in fig. 5, a node device to which any one of the subnet1 and subnet2 belongs may be deployed with a corresponding database and a corresponding virtual machine, and taking fig. 5 as an example, nodeD1 in subnet1 is specifically a blockchain node instance (hereinafter referred to as blockchain node) formed by the node device 4 running a pre-deployed blockchain platform code in a locally deployed virtual machine, and nodeD1 is stored in a database corresponding to nodeD1 as related data of the blockchain node in the running process. 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 there is no other blockchain network established based on the blockchain network). In other words, the cross-chain interaction method described in this specification may be applied to any two blockchain networks, and the mutual relationship between the blockchain network and other blockchain networks is not limited in this specification. In addition, a blockchain consensus code can be deployed in the node device, and the node device can run the consensus code to locally form a consensus plug-in instance; and the node device can also be deployed with P2P plug-in codes managed in a plug-in form, and the node device can run the P2P plug-in codes to locally form a P2P plug-in instance, namely a P2P plug-in. The node device is also provided with a blockchain service code, and the node device can run the blockchain service code to locally form a service instance, where any node device can implement at least one service instance, such as a storage instance for implementing a data read/write function, a calculation instance for implementing a calculation function such as privacy calculation, and an encryption instance for implementing a data encryption function, and details are not repeated.

In particular, when the cross-chain interaction method described in this specification is applied to two blockchain subnets under management of a blockchain master network, a master node in the blockchain master network is deployed on node devices to which a source node in a source blockchain network or a destination node in a destination blockchain network belongs, and with reference to fig. 4 and 5, a master node nodeb is also deployed on a node device 4 to which nodeb1 in a subnet1 belongs, and a master node nodeb is also deployed on a node device 5 to which nodeb2 in a subnet2 belongs, since a P2P plug-in on a node device can be shared by each blockchain node on the node device, although there is no direct network connection link between the nodeb net 493 2 and the subnet2, since the nodeb deployed on the node device 4 and the nodeb e deployed on the node device 5 have previously established a network connection link based on a P2, a P4835 connection plug-in a network 466 running through the P2 plug-in the subnet 466, by means of the network connection link realized when the subnet0 is formed, a network connection is established between the P2P plug-in running on the node device (e.g., node device 5) to which each destination node (e.g., node e 2) in the subnet2 belongs, thereby further realizing network communication with the destination node, so that network communication between the source node and the destination node in the source blockchain network is realized through the network connection link pre-established by the bottom layer blockchain main network without establishing a new network connection link between the source blockchain network and the destination blockchain network.

Each node in the subnet1 may need to use data stored by each node in the subnet2 in the process of implementing a service function, so that the subnet1 may request the subnet2 to acquire the data, and in the process of acquiring the data through the cross-chain interaction scheme described in this specification, the subnet1 is a source blockchain network, and the subnet2 is a destination blockchain network. For example, subnet1 may send a cross-chaining request to subnet2 in an attempt to obtain the contract state for a particular field in a particular contract held in the subnet 2's node database. It is to be understood that "subnet 1 sends a cross-link request to subnet 2" is "subnet node (i.e., source node) in subnet1 sends a cross-link request to subnet node (i.e., destination node) in subnet 2".

Specifically, when the cross-chain interaction method described in this specification is applied to two blockchain subnets under management of a blockchain main network, any node in the subnet1 may encapsulate a network identifier of the target blockchain network subnet2 in a cross-chain request, and broadcast the cross-chain request to a P2P plug running on each node device deployed with the main network node through a network connection link of the subnet0 by calling a P2P plug locally deployed by the node device and shared with the main network node in the subnet 0. In an embodiment, if the nodeA1 in the subnet1 sends out the cross-link request through the P2P plug-in on the node device 1, then all 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 plug-in on the node device 5 will determine, according to the network identifier carried in the cross-link request, whether the node device 5 is locally deployed with a blockchain link point in the blockchain network corresponding to the network identifier, obviously, the nodeE2 in the subnet2 is deployed on the node device 5, and therefore, the P2P plug-in on the node device 5 will further forward the cross-link request to the nodeE2 based on the network identifier, and after receiving the cross-link request, the P2P plug-in the node device 4 will also forward based on the network identifier carried by the plug-in the node device 4, but since the node device 4 is not locally deployed with a blockchain link point in the subnet2, the node device will not retain the cross-link request, but further forwards the cross-link request to other node devices deployed with the primary network node. In addition, any node in the subnet1 can encapsulate, in addition to the network identifier in the cross-link request, the identity information of any node in the destination blockchain network, such as the node ID and the node public key, in the cross-link request, so that, in the process of invoking the P2P plugin to implement the cross-link transmission cross-link request, the P2P plugin can directly send to the node device specified by each node identity information carried in the cross-lead request in a point-to-point communication manner without sending to the node device to which each main network node belongs in a broadcast manner, for example, the nodeD1 in the subnet1 can encapsulate the identity information of the nodeE2 in the cross-link request and invoke the P2P plugin locally running in the node device 4, so that the P2P plugin can send the cross-link request to the nodeE2 deployed in the subnet2 and the node device 355 in the subnet0 in a unicast manner according to the identity information of the nodeE2, and then receive the P2 plugin on the node device 2P in the cross-link request, in addition to forwarding the cross-chain request to nodeE2 through the network identifier carried by the cross-chain request, the cross-chain request may also be forwarded to nodeE2 directly through the identity information of nodeE2 carried by the cross-chain request.

The above process describes a process in which the source blockchain network sends a message request to the destination blockchain network through a network connection link established by the blockchain master network, and similarly, the destination blockchain network may also implement message transmission to the source blockchain network by calling a local P2P plug-in, for example, returning cross-link data corresponding to the blockchain request sent by the source blockchain network to the source blockchain network, thereby implementing network communication between the source node in the source blockchain network and the 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 a main network node in the subnet0, and the main network node forwards the request to the corresponding subnet2, where a destination node in the subnet2 may verify the received data acquisition request in order to ensure the validity of the responded data acquisition request, and respond when the verification is passed. The destination node responds to the data acquisition request, that is, determines data executed by the received data acquisition request (i.e., data required by subnet 1), and generates a cross-link message based on the data and returns the cross-link message to subnet1 through the master network node in subnet 0. Similarly, the source node in the subnet1 may also perform validity verification on the received cross-chain message, and if the verification is passed, use the data contained in the cross-chain message to continue implementing the relevant service function.

Fig. 5 is merely an exemplary illustration of the tile chain subnet1 and subnet2 in conjunction with fig. 4. In fact, cross-chain interaction can be implemented between each blockchain network in fig. 4, and the description does not limit the relationship between blockchain networks interacting across chains. For example, cross-chain interaction may be implemented between the blockchain main network subnet0 and the blockchain subnet1, between the blockchain main network subnet0 and the blockchain subnet3 (i.e., the grandchild of subnet 0), between the blockchain subnet2 and the subnet3, and the like, and detailed processes are not described again.

The cross-chain interaction scheme of the present specification is described in detail below with reference to fig. 6. Referring to fig. 6, fig. 6 is a schematic diagram of a cross-chain 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 the method may include the following steps:

step 602, at least one source node in a source block chain network initiates a cross-chain request to a destination block chain network, so that each destination node in the destination block chain network obtains the cross-chain request respectively.

Step 604, each source node obtains a cross-link message returned by each destination node in response to the cross-link request.

In this embodiment, a source node in a source blockchain network may initiate a cross-chain request to a destination blockchain network, so that each destination node in the destination blockchain network may return a cross-chain message to the corresponding source node in response to the cross-chain request, so that each source node generates a blockchain transaction according to the obtained cross-chain message.

In an embodiment, in order to ensure privacy of the initiated cross-link request and avoid leakage of the content of the request, any source node may perform encrypted transmission on the cross-link request to be transmitted by using a digital envelope technology, where the request corresponds to a specific service that the source node needs to complete, and may be used to invoke an intelligent contract, and the request content may include related parameters, contract information of the invoked contract, functional information in the invoked contract, and the like. Specifically, the source node may sign the request content by using its own node private key, encrypt the request content and its signature by using a symmetric key, then encrypt the symmetric key by using the node public key of each destination node, and add the request content and its signature encrypted by the symmetric key and a digital envelope composed of each symmetric key encrypted by the node public key of each destination node to the cross-link request. Correspondingly, any destination node receiving the cross-link request can decrypt the encrypted symmetric key contained in the request through the node private key of the destination node, further decrypt the encrypted symmetric key to obtain request content and a signature, and then verify the signature through the node public key of the source node. If the verification passes, the received request content is really sent by the corresponding source node (not tampered), so that the request content can be subjected to subsequent processing to return a corresponding cross-link message to the source blockchain network. Therefore, after receiving the cross-link request, each destination node can decrypt the symmetric key by using the own node private key respectively, and further decrypt the cross-link request by using the decrypted symmetric key, and determine information acquired by the source node request according to the information, such as to-be-processed data and the like required by implementing the service function.

After determining the information requested to be acquired by the source node, the destination node may generate a cross-link message containing the information. Similarly, the destination node may also encrypt the cross-chain message using the digital envelope technique described above. For example, the destination node may encrypt the information using a symmetric key, encrypt the symmetric key using a node public key of each source node, and add the encrypted information and each encrypted symmetric key to the cross-chain message; correspondingly, each source node receiving the cross-link message can decrypt the symmetric key encrypted by the self-node public key in the cross-link message through the self-node private key respectively, and the information is obtained through decryption of the symmetric key. Therefore, after receiving the cross-link message, each source node can decrypt the encrypted symmetric key contained in the cross-link message by using the private key of the node of the source node, and further decrypt the information requested to be acquired by the source node by using the symmetric key.

Taking fig. 4 as an example, when the subnet1 initiates a cross-chain request to the subnet2 and the subnet2 returns a cross-chain message to the subnet1, the subnet1 is a source blockchain network and the subnet2 is a destination blockchain network. Any subnet node nodeB1 in subnet1 may encrypt the symmetric key using the node public key of each subnet node nodeB2, nodeB2, nodeB2, and nodeB2 in subnet2 after encrypting the blockchain message using the symmetric key, and include the encrypted symmetric key and blockchain message in a cross-chain request to be sent to subnet2 through subnet 0. After any subnet node (e.g., nodeA 2) in subnet2 receives the cross-chain request, it is determined that the subnet node is a legitimate receiver of the cross-chain request when it is determined that the private key of the subnet node can decrypt the symmetric key encrypted in the cross-chain request, and the block chain message can be decrypted by using the decrypted symmetric key. Similarly, after the nodeA2 generates the cross-chain message, the same method may be used to encrypt the cross-chain message, and details are not described again.

It can be understood that, by using the digital envelope technology, the node public keys of multiple destination nodes can be used to encrypt the symmetric key at the same time, so that any source node can use the public keys of all the destination nodes in the destination block chain network to encrypt the block chain message and include the block chain message in the cross-chain request, any destination node can use the public keys of all the source nodes in the source block chain network to encrypt the information requested by the source node and include the information in the cross-chain message, and then each destination node can decrypt the block chain message in the cross-chain request according to its own node private key, and each source node can decrypt the information in the cross-chain request according to its own node private key, thereby realizing the effect that the source node broadcasts the cross-chain request to the destination node, and the destination node broadcasts the cross-chain message to the source node. Of course, under the condition of adopting the digital envelope manner, any source node may also encrypt the symmetric key in the cross-link request only by using the node public key of one (or more) destination node(s), and any destination node may also encrypt the symmetric key in the cross-link message only by using the node public key of one (or more) source node(s), so as to realize the effect that the source node unicasts (or multicasts) the cross-link request to the destination node and the destination node unicasts (or multicasts) the cross-link message to the source node, and the specific process is not described again. In fact, the present specification does not limit the specific sending manner of the above-mentioned cross-link request and the cross-link message, for example, a node public key is directly used to encrypt the block chain message in the cross-link request or the data to be processed in the cross-link message without using a digital envelope, or the cross-link request is broadcast and the cross-link message is unicast, and details are not repeated.

As described above, each source node in the source blockchain network may respectively initiate (i.e., broadcast) a cross-chain request to each destination node in the destination blockchain network, or each source node may also respectively initiate (i.e., unicast or multicast) a cross-chain request to any one (or more) destination nodes in the destination blockchain network, and each destination node synchronizes its received cross-chain request to other destination blockchain networks in the destination blockchain network. Therefore, whether the cross-link request is initiated in a broadcast mode or initiated in a unicast or multicast mode and is synchronized in the network to which the receiver belongs, each destination node in the destination block chain network can be ensured to receive the cross-link request initiated by each source node in the source block chain network. In addition, the cross-link message may be returned to the source block link network by each destination node in a unicast or broadcast manner. For example, any destination node may use the broadcast method (the digital envelope encrypts the symmetric key using the node public key of each subnet node in the source block chain network) described in the foregoing embodiment, and may also determine the sender of the cross-chain request according to the cross-chain request received by itself, and further only return a corresponding cross-chain message to the sender. For example, after receiving a cross-chain request initiated by a source node a1 in subnet1 in a unicast manner, a destination node a2 in subnet2 may return a corresponding cross-chain message to the node a1 only, and synchronize the cross-chain message to other source nodes such as a node b1, a node c1, and a node d1 in a source block chain network by a node a1 after receiving the cross-chain message. Obviously, the two manners can ensure that each source node in the source block chain network receives the cross-chain message returned by each destination node in the destination block chain network.

In an embodiment, the source blockchain network may be a blockchain subnet managed by a blockchain master network, the blockchain master network may maintain node identity information of each source node in the active blockchain network, and the cross-chain request may include identity identification information used for characterizing a node identity of the source node initiating the cross-chain request, at this time, each destination node receiving the cross-chain request may respectively query the blockchain master network for the node identity information of the source node initiating the cross-chain request to check the identity identification information, and respond to the cross-chain request if the check passes. Similarly, the target blockchain network may also be a blockchain subnet managed by a blockchain master network, where the blockchain master network maintains node identity information of each destination node in the target blockchain network, the cross-chain message includes identity information used to characterize the node identity of the destination node returning the cross-chain message, and correspondingly, each source node may respectively query the blockchain master network for the node identity information of the destination node returning the cross-chain message to verify the identity information, and generate a blockchain transaction according to the cross-chain message passing the verification.

Taking fig. 4 as an example, the blockchain master network subnet0 may maintain node identity information of each subnet node in the blockchain subnets subnet1 and subnet 2. It can be understood that the cross-chain request initiated by the source node nodeb1 received by the destination node nodeb2 may include identification information of nodeb1, so that the nodeb2 may determine that the source node corresponding to the request (i.e., the initiator of the request) is nodeb1, and thus the nodeb2 may query the main blockchain subnet0 for node identity information of nodeb1, and determine whether nodeb1 is a legitimate source node according to the node identity information returned by subnet 0. Certainly, the nodeA2 may also initiate a query request carrying identification information of nodeA1 to the subnet0, receive a query result returned by the subnet0, and determine whether the nodeA1 is a legal source node according to the query result. The node identity information stored in the subnet0 may include a network address, a port, a node public key, and/or a node identifier of the node. Taking a node public key as an example, the nodeA2 may initiate an inquiry request including the node public key of the nodeA1 carried in the cross-link request to the master network node a in the subnet0, at this time, a may inquire whether the node public key of the nodeA1 exists in the node public keys of the locally maintained subnet nodes, and return a corresponding inquiry result to the nodeA2, so that the nodeA2 may implement verification of the node public key of the nodeA1 according to the inquiry result. If the node public key of nodeA1 is queried, the check is passed, that is, nodeA1 is indeed the trusted initiator of the cross-chain request received by nodeA2, so that nodeA2 can further respond to the cross-chain request; otherwise, if the node public key of nodeA1 is not queried, the check is failed, that is, nodeA1 is not trusted, and at this time, nodeA2 may directly discard the cross-chain request initiated by nodeA 1. In addition, in the case of failed verification, the nodeA2 may also record nodeA1 as an illegal source node, so that in the case of subsequently receiving a cross-chain request initiated by nodeA1 again, the request may be directly discarded, thereby avoiding invalid processing and speeding up response.

Similarly, after receiving the cross-chain message returned by the nodeb2, the nodeb1 may also request the a in the subnet0 to query the node identity information of nodeb2 according to the identity information of nodeb2 carried in the cross-chain message, so as to verify the identity information of nodeb 2. If the check is passed, it indicates that the nodeb2 is indeed the trusted initiator of the cross-chain message received by nodeb1, so that nodeb1 may further generate a blockchain transaction according to the received cross-chain message, and a specific generation process of the blockchain transaction may refer to the following embodiments, which are not described herein again; otherwise, if the check is not passed, it indicates that nodeA2 is not trusted, and at this time, nodeA1 may directly discard the cross-chain message. Of course, in the case that the verification fails, the nodeb1 may also record nodeb2 as an illegal destination node, so that in the case that a chain crossing message returned by nodeb2 is received again in the following, the information may be directly discarded, thereby avoiding the invalidation process and increasing the response speed. Of course, in the case of initiating a cross-chain request in a unicast manner, if the nodeA1 records nodeA2 as an illegal destination node, nodeA1 may refuse to initiate a cross-chain request to nodeA2, and may even synchronize the illegal recording of nodeA2 to other source nodes in subnet 1.

In the foregoing embodiment in which the source blockchain network or the destination blockchain network is a blockchain subnet, when a main network node in the blockchain main network and a subnet node in the blockchain subnet managed by the blockchain main network are deployed in the same node device, the main network node and the subnet node on the node device may share a blockchain plug-in running on the node device, and at this time, any blockchain link point may query node identity information of any subnet node through the blockchain plug-in, for example, the node identity information of any subnet node maintained by the main network node may be read through the blockchain plug-in shared with the main network node deployed on the node device to which the block chain node belongs. Taking fig. 4 as an example, if the master node a, the sub-network node a1, and the sub-network node a2 are all deployed in the same node device (hereinafter referred to as node device a), the three may share a blockchain plug-in running on the node device a. For example, nodeA1 can query the node identity information of nodeA2 through a blockchain plug-in, and nodeA2 can query the node identity information of nodeA1 through a blockchain plug-in. The blockchain plug-in may be a plug-in 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 in a manner that a corresponding main network node initiates a transaction (for example, reads subnet node information maintained by a subnet management contract) for invoking the subnet management contract in subnet 0. Of course, to ensure query speed, the transaction may be a transaction that does not require consensus. Obviously, under the condition that network nodes belonging to different blockchain networks are deployed in the same node device, the blockchain plug-ins of the node device are shared by all the nodes, so that the efficient multiplexing of the blockchain plug-ins can be realized, the number of the blockchain plug-ins needing to be deployed in the node device is effectively reduced, the configuration of the node device and the deployment process of the blockchain nodes are facilitated to be simplified, and the deployment efficiency of the blockchain nodes and the management efficiency of the node device are improved. In fact, different block link points deployed in the same node device may also share other functional plug-ins, such as the aforementioned P2P plug-in example, consensus plug-in example, and/or service example, and are not described again.

In the foregoing embodiment in which the source blockchain network or the destination blockchain network is a blockchain subnet, a subnet management contract may be deployed on the blockchain main network, where the subnet management contract is used to maintain node identity information of subnet nodes in each blockchain subnet established based on the blockchain main network; at this time, any one of the block nodes may read the node identity information of any one of the subnet nodes maintained by the subnet management contract. Taking fig. 4 as an example, because subnet1 to which subnet node nodeA1 belongs and subnet2 to which subnet node nodeA2 belongs are both established on the basis of subnet0, the subnet management contract deployed in subnet0 may be used to manage node identity information of each subnet node in subnet1 and subnet2, and further, any source node may read node identity information of any destination node maintained by the subnet management contract, and any destination node may also read node identity information of any source node maintained by the subnet management contract. Therefore, the node identity information of the subnet nodes is maintained through the subnet management contract deployed in the blockchain main network, and the efficient management of the node identity information can be ensured. And 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 process of 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 source blockchain network or 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 the blockchain subnet to which the subnet node belongs; any blockchain node queries the blockchain master network about the node identity information of any subnet node, which may include: and any blockchain node inquires whether the node identifier and the subnet identifier declared by any subnet node are matched with each other from the blockchain main network. Taking fig. 4 as an example, the node identity information contained in the cross-chain request initiated by the subnet node nodeb1 to nodeb2 may include the node identifier of nodeb1 and the subnet identifier of subnet 1; similarly, the node identity information contained in the cross-chain message returned by the sub-network node nodeb2 to nodeb1 may include the node identity of nodeb2 and the sub-network identity of subnet 2. Therefore, after receiving the cross-chain request initiated by the nodeb1, the nodeb2 may query the subnet0 whether the node identifier and the subnet identifier declared by the nodeb1 match, for example, the nodeb2 may query the main network node a whether the subnet identifier maintained by the main network node a includes the subnet identifier of the subnet1, and if so, further query whether the node identifier of the nodeb1 is included in all the node identifiers corresponding to the subnet identifier of the subnet 1: if the node identifier of nodeA1 is included, it indicates that the node identifier declared by nodeA1 matches with the subnet identifier, and further indicates that the cross-chain request received by nodeA2 indeed originated from nodeA1, so nodeA2 can further respond to the request; otherwise, if the node id of nodeA1 is not included, it indicates that the node id declared by nodeA1 and the subnet id do not match, and further indicates that the cross-link request received by nodeA2 may be a false request initiated by another node, and therefore, the response to the request may be terminated. Similarly, after receiving the cross-chain message returned by the nodeb2, the nodeb1 may query the subnet0 whether the node identifier and the subnet identifier declared by nodeb2 match, and then perform corresponding processing according to the query result, for example, in the case that the node identifier and the subnet identifier match, generate a blockchain transaction according to the received cross-chain message; or under the condition that the two are not matched, directly discarding the cross-chain message is terminated, and the like, which is not described any more. By the method, the node identity information of each subnet node maintained in the block chain main network can be fully utilized to verify the chain crossing request initiated by the subnet node or the chain crossing message sent by the subnet node, so as to ensure the legality of the subsequently processed request or message.

In the foregoing embodiment in which the source blockchain network or 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, the querying, by any blockchain node, node identity information of any subnet node from the blockchain master network to check the identity information may include: and any block chain node inquires the node public key of any subnet node from the block chain master network, and the signature is checked by adopting the node public key. Taking fig. 4 as an example, the sub-network node nodeb1 may generate a signature for the blockchain message included in the cross-chain request (or for the cross-chain request) based on its own node private key, and include the signature in the cross-chain request (or initiate association with the cross-chain request) to the sub-network node nodeb2, so that the nodeb2 may, after receiving the cross-chain request and the signature, query the subnet0 for node identity information of the nodeb1 to check the signature, e.g., check the signature according to the node public key of the nodeb1 queried from the subnet 0. Thus, in the case of passing the verification, the cross-chain request can be further responded; in the event of a failed signature verification, the response to the cross-chain request may be terminated, such as the cross-chain request may be directly discarded or even nodeA1 may be recorded as an illegal node. Similarly, after receiving the cross-chain message and the corresponding signature returned by the nodeA2, the nodeA1 may also request the subnet0 to acquire the node public key of the nodeA2 and check and sign the signature, and then perform corresponding processing according to the result of checking and signing: under the condition that the signature verification passes, block chain transaction can be generated according to the cross-chain message; in the event of a failed signature verification, the response to the cross-chain message may be terminated, such as the cross-chain message may be directly discarded or even nodeA2 may be recorded as an illegal node.

And 606, generating a block chain transaction by each source node according to the acquired cross-chain message, and submitting the generated block chain transaction to the source block chain network.

After each source node in the source blockchain network acquires the cross-chain message, a blockchain transaction can be generated according to the cross-chain message acquired by the source node. Of course, in embodiments corresponding to the foregoing, the source node may generate the blockchain transaction from the check-passed, information-matched, or signature-checked-passed cross-chain message. Furthermore, each source node may submit the generated information blockchain transaction to a blockchain network where the source node is located, so that each node in the network performs the blockchain transaction after passing through the blockchain transaction consensus.

In an embodiment, each source node may perform byzantine fault tolerance verification on the acquired cross-link message according to the message quantity of the cross-link message acquired by the source node and the total node quantity of the destination node in the destination block chain network, and generate a block chain transaction according to the cross-link message passing the verification. As can be seen from the foregoing implementation, any source node may receive multiple interlinkage messages returned by multiple destination nodes, so after receiving an interlinkage message, any source node performs byzantine fault tolerance verification on the interlinkage message acquired by itself according to the message number of the interlinkage message acquired by itself and the total node amount of the destination node in the destination blockchain network, and generates a blockchain message only according to the interlinkage message passing the verification, thereby ensuring the reliability of the interlinkage message used for generating the blockchain message, and further ensuring the reliability of the generated blockchain message.

In the case that the target blockchain network is a blockchain subnet managed by a blockchain master network, the blockchain master network may maintain a total amount of nodes of a target node in the target blockchain network, so that each source node may query the total amount of nodes from the blockchain master network. For example, the subnet node nodeB1 may receive the span message returned by one or more nodes of the subnet nodes nodeB2, nodeB2, nodeB2, and nodeB2, respectively, so that nodeB1 may query the subnet0 for the total amount of nodes of the destination blockchain node in the destination blockchain network, and then perform a bayesian fault tolerance check on the received span message according to the total amount of nodes and the number of messages of the span message received by itself. At this time, subnet information of the blockchain subnet maintained by the blockchain main network can be fully utilized, which is helpful for improving interaction efficiency. In addition, in the scenario of the blockchain main network and the blockchain sub-network provided in each embodiment, after the blockchain sub-network queries information from the blockchain main network, the corresponding information can be stored locally, so as to avoid repeated queries in a subsequent processing process, and further improve interaction efficiency. Of course, to ensure the timeliness of the information, an effective time duration may be set for the locally stored information, and the information may be updated in real time.

In an embodiment, the cross-link message may include data to be processed, so that each source node may perform bayesian fault tolerance check on the cross-link message acquired by itself according to the number of the cross-link messages including the same data to be processed and the total number of nodes of the destination node in the destination block chain network. As described above, since the multiple cross-link messages received by any source node are generated in response to the cross-link request initiated by the source node, the multiple cross-link messages received by any source node should contain the same data to be processed in the absence of an illegal destination node. Therefore, for a plurality of cross-link messages received by any source node, the source node can compare the data to be processed contained in each cross-link message, and count the message quantity of the cross-link messages containing the same data to be processed, so as to perform the Byzantine fault-tolerant check on the received cross-link messages according to the message quantity and the total node quantity of the target node in the target block chain network. In the following, only the example that the sub-network node nodeA1 adopts the PBFT byzantine fault-tolerant algorithm is described with reference to the scenario shown in fig. 4. As can be seen from fig. 4, the subnet2 serving as the destination blockchain network includes four subnet nodes (total number of nodes is 3f +1=4, that is, f = 1), including nodeA2, nodeB2, nodeC2 and nodeE2, so that if the nodeA1 receives a legal crosslink message returned by at least f +1 (that is, 2) subnet nodes and includes the same data to be processed, it can be determined that the crosslink messages pass the bypath fault tolerance check. Of course, in the practice of the solution, the total amount of the nodes and the number of messages received in the cross-chain message may also be other values, and this specification does not limit this. Wherein the cross-chain message (containing the same data to be processed) that passes the above-mentioned verification is used to generate the blockchain transaction.

In another embodiment, the cross-chain message may include data to be processed, and at this time, each source node may verify the blockchain transaction synchronized with other source nodes 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 synchronized with other source nodes, and perform consensus on the blockchain transactions that pass the verification. For example, each source node in the source blockchain network may use the to-be-processed data carried in the received cross-chain message as the first to-be-processed data (as described above, the cross-chain message received by the same source node or the cross-chain message passing through the byzantine fault tolerance check carries the same to-be-processed data). Each source node synchronizes the self-generated blockchain transaction to other source nodes in the source blockchain network, so that the to-be-processed data extracted from the received blockchain transactions synchronized by other source nodes can be used as second to-be-processed data. And then, by comparing whether the first data to be processed and the second data to be processed are the same, the block chain transaction synchronized by other source nodes is verified: under the condition that the first to-be-processed data is the same as the second to-be-processed data, the blockchain transaction can be determined to pass verification; otherwise, under the condition that the first to-be-processed data is different from the second to-be-processed data, the blockchain transaction is determined not to pass the verification.

Or, in order to improve the verification efficiency of the blockchain transaction generated by other source nodes, the blockchain transaction generated by any source node may also carry the hash of the data to be processed, so that other source nodes may use the hash as the second hash, and use the hash of the data to be processed carried in the cross-chain message received by the source node as the first hash. Further, by comparing whether the first hash and the second hash are the same, the verification of the blockchain transaction synchronized by other source nodes is realized: 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, under the condition that the first hash is not the same as the second hash, determining that the blockchain transaction is not verified. In general, the data volume of the data to be processed is much larger than that of the hash, so that the verification efficiency can be effectively improved by comparing the hashes.

It will be appreciated that only blockchain transactions that are verified by each source node in the source blockchain network will be executed through consensus and have an opportunity. For any blockchain transaction, a workload certification, a share right certification, a commission rights certification, a practical Byzantine fault-tolerant algorithm, a HoneyBadgerBFT algorithm and the like can be adopted for consensus, and the specific process is not repeated.

In step 608, each source node performs the same blockchain transaction among the plurality of blockchain transactions through the common identification.

Because each source node in the source blockchain network generates blockchain transactions according to the verified cross-chain message acquired by the source node, a plurality of blockchain transactions corresponding to the same cross-chain request may share the same identification in the source blockchain network, but in order to ensure consistency of execution results of the blockchain transactions, each source node is required to execute the same blockchain transaction passing the common identification, so that the same service effect is achieved. In order to ensure that each source node in the source blockchain network respectively executes the same blockchain transaction through consensus, each source node can respectively execute the first blockchain transaction through consensus in the source blockchain network. Alternatively, the blockchain transaction generated first in the identified blockchain transactions may be executed, for example, each source node may ensure that the executed blockchain transaction is the first blockchain transaction generated according to the timestamp carried by the blockchain transaction. After any source node executes the blockchain transaction, the processing process for other blockchain transactions can be terminated. For example, if any blockchain transaction carries a request identifier, the source node may not execute the new blockchain transaction (i.e., does not execute contract code related to a specific service) when receiving the new blockchain transaction carrying the same request identifier as the executed blockchain transaction. Certainly, the source node may also receive a plurality of blockchain transactions carrying the same request identifier in a short time, and perform processing such as checking, execution and the like on each transaction in sequence according to the time sequence of receiving each transaction, so that the processing progress of each blockchain transaction may be different, and after the first blockchain transaction is executed, the source node may immediately terminate the execution process for other blockchain transactions, so as to ensure that only the first blockchain transaction is executed smoothly, so that a consistent transaction execution result is maintained with other source nodes, and computational power loss caused by invalid processing is reduced.

Because the source blockchain network may participate in the processing of multiple inter-chain requests at the same time (e.g., initiating a second inter-chain request when the processing of the first inter-chain request has not ended), and the destination blockchain network may respond to multiple inter-chain messages at the same time (e.g., receiving a second inter-chain request when the responding of the first inter-chain request has not ended), to avoid confusion between different inter-chain requests or different inter-chain messages, the association between the inter-chain requests and the inter-chain messages may be achieved through request identification. For example, in the case where the cross-chain request is generated by the source node executing an intelligent contract, the cross-chain request may use a contract identifier (such as a contract address, a contract label, a contract name, etc.) of the intelligent contract as its own request identifier; or, in the case that the cross-chain request is generated by a source node executing a certain contract task defined in an intelligent contract, the cross-chain request may use a task identifier of the contract task as its own request identifier, and further, a cross-chain message generated by a destination node in response to any cross-chain request also includes the request identifier of the request, thereby ensuring that the cross-chain request initiated by each source node and the cross-chain message returned by each destination node both include the request identifier. Namely, each cross-chain request initiated by each source node aiming at the same intelligent contract (or contract task) is associated through the request identifier, and each cross-chain message returned by each target node responding to each cross-chain request corresponding to the request identifier is associated through the request identifier, so that the association of all cross-chain requests and all cross-chain messages corresponding to the same intelligent contract (or contract task) is realized, and the effective differentiation between different cross-chain requests or different cross-chain messages is facilitated.

Accordingly, the source blockchain network may maintain a request identification set for recording the request identifications of the respective cross-chain requests that have not been responded to (i.e., whose corresponding blockchain transaction has not been performed) in which the source blockchain network participates at the current time. Thus, each source node may perform any one of a plurality of blockchain transactions through consensus, respectively, by: each source node can respectively determine whether a target request identifier carried in any blockchain transaction corresponding to the source node exists in the request identifier set; and executing any blockchain transaction corresponding to the blockchain transaction under the condition that the target request identifier exists in the request identifier set. It can be understood that the combination of the request identifiers includes a target request identifier, which indicates that all blockchain transactions corresponding to the target request identifier are not executed, so that each source node can implement a response to the inter-chain request only by executing the blockchain transaction. Of course, after any source node executes the blockchain transaction corresponding to a certain request identifier, the request identifier may be deleted from the request identifier set maintained by itself, so as to ensure that other blockchain transactions corresponding to the request identifier are not repeatedly executed.

In an embodiment, the cross-chain message may include data to be processed, and the cross-chain request may be created by a source node invoking an intelligent contract deployed in a source blockchain network; correspondingly, the source node can call an intelligent contract task callback method in response to the cross-link message so as to return the data to be processed to the intelligent contract. In the embodiment of accepting the automatic login user account, it is assumed that the source node executes an intelligent contract for implementing login of the user account, but the source node does not locally store the user account and the login password, so that the source node may generate a cross-link request for acquiring the user account and the login password, and after a destination node in the destination blockchain network returns a cross-link message in response to the request, the source node may implement automatic login of 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 the data to be processed, and the source node returns the user account and the login password to the intelligent contract for realizing the service function.

Through the embodiment, under the condition that different nodes in the source blockchain network receive a plurality of blockchain messages returned by different nodes in the destination blockchain subnet, the source node can generate blockchain transactions according to the blockchain messages acquired by the source node, and any source node only executes any commonly-identified blockchain transaction, so that the consistency of processing the blockchain messages returned by the destination blockchain network by each node in the source blockchain network is effectively ensured, and the problems are effectively solved.

Fig. 7 is a schematic diagram of an apparatus according to an exemplary embodiment. Referring to fig. 7, at the hardware level, the apparatus includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile storage 710, but may also include hardware required for other services. One or more embodiments of the present description can be implemented in software, such as by the processor 702 reading corresponding computer programs from the non-volatile storage 710 into the memory 708 and then executing. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.

FIG. 8 is a block diagram of a cross-chain interaction device, provided in 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. Wherein, the cross-chain interaction device may include:

a request initiating unit 801, configured to enable at least one source node in a source block chain network to initiate a cross-chain request to a destination block chain network, so that each destination node in the destination block chain network obtains the cross-chain request respectively;

a message receiving unit 802, which enables each source node to obtain a cross-link message returned by each destination node in response to the cross-link request;

a transaction submitting unit 803, which enables each source node to generate a blockchain transaction according to the acquired cross-chain message, and submits the generated blockchain transaction to the source blockchain network;

the transaction execution unit 804 enables each source node to execute the same blockchain transaction in the plurality of commonly-identified blockchain transactions.

Optionally, the method further includes:

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

the request decryption unit 806 is configured to enable each destination node to decrypt, by using its own node private key, the symmetric key encrypted by using its own node public key in the inter-link request, decrypt, by using the symmetric key obtained through decryption, the encrypted blockchain message and the signature, and return, by using the node public key of the source node, the inter-link message to the source blockchain network according to the blockchain message obtained through decryption when the signature passes the verification of the signature.

Optionally, the cross-link message is returned to the source block link network by each destination node in a unicast or broadcast manner.

Optionally, the source blockchain network is a blockchain subnet managed by a blockchain master network, the blockchain master network maintains node identity information of each source node in the source blockchain network, and the cross-chain request includes identity identification information used for characterizing a node identity of a source node initiating the cross-chain request; the device further comprises:

the source node verifying unit 807 is configured to enable each destination node to query, to the blockchain master network, node identity information of a source node that initiates the cross-chain request, so as to verify the identity information, and respond to the cross-chain request when the verification passes.

Optionally, the target blockchain network is a blockchain subnet managed by a blockchain master network, the blockchain master network maintains node identity information of each destination node in the target blockchain network, and the cross-chain message includes identity identification information used for representing a node identity of the destination node returning the cross-chain message; the device further comprises:

the destination node identity verification unit 808 is configured to enable each source node to query the master network of the blockchain and return the node identity information of the destination node of the cross-chain message to verify the identity information, and generate the blockchain transaction according to the cross-chain message passing the verification.

Optionally, when the master network node in the block chain master network and the subnet node in the block chain subnet managed by the block chain master network are deployed in the same node device, the master network node and the subnet node on the node device share the block chain plug-in running on the node device; the source node verifying unit 807 or the destination node identity verifying unit 808 is further configured to:

and enabling any blockchain node to read the node identity information of any subnet node maintained by the main network node through a blockchain plug-in shared by the blockchain node and the main network node deployed on the node equipment of the blockchain node.

Optionally, a subnet management contract is deployed on the blockchain main network, where the subnet management contract is used to maintain node identity information of subnet nodes in each blockchain subnet established based on the blockchain main network; the source node verifying unit 807 or the destination node identity verifying unit 808 is further configured to:

and enabling any block chain node to read the node identity information of any subnet node maintained by the subnet management contract.

Optionally, the identification information of any subnet node includes a node identifier declared by any subnet node and a subnet identifier of a block chain subnet to which the any subnet node belongs; the source node verifying unit 807 or the destination node identity verifying unit 808 is further configured to:

and any block chain node queries whether the node identifier and the subnet identifier declared by any subnet node are matched with each other from the block chain main network.

Optionally, the identification information of any subnet node includes a signature generated by the subnet node based on its own private key; the source node verifying unit 807 or the destination node identity verifying unit 808 is further configured to:

and any block chain node queries the node public key of any subnet node from the block chain main network, and the node public key is adopted to verify the signature.

Optionally, the method further includes:

the message verification unit 809 is configured to enable each source node to perform byzantine fault-tolerant verification on the acquired cross-link message according to the number of the cross-link messages acquired by the source node and the total number of nodes of the destination node in the destination block chain network, and generate the block chain transaction according to the cross-link messages passing the verification.

Optionally, the destination blockchain network is a blockchain subnet managed by a blockchain master network, and the blockchain master network maintains a total amount of nodes of a destination node in the destination blockchain network, where the apparatus further includes:

the total amount query unit 810 is configured to enable each source node to query the total amount of the nodes to the block chain master network.

Optionally, the cross-chain message includes data to be processed, and the message checking unit 809 is further configured to:

and enabling each source node to carry out Byzantine fault-tolerant check on the acquired cross-chain message according to the number of the cross-chain messages containing the same data to be processed and the total number of nodes of the target node in the target block chain network.

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

the transaction checking unit 811 enables each source node to check the blockchain transaction synchronized with 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 synchronized with other source nodes, or according to the first hash calculated 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 synchronized with other source nodes, and to commonly identify the blockchain transactions passing the check.

Optionally, the source block chain network maintains a request identifier set, a cross-chain request initiated by each source node and a cross-chain message returned by each destination node include the same request identifier, and the transaction execution unit 804 is further configured to:

enabling each source node to respectively determine whether a target request identifier carried in the blockchain transaction exists in the request identifier set;

and enabling each source node to execute the blockchain transaction and delete the target request identifier from the request identifier set under the condition that the target request identifier exists in the request identifier set.

Optionally, the cross-chain message includes data to be processed, and the apparatus further includes:

a contract invoking unit 812 that causes the source node to invoke an intelligent contract deployed in the source blockchain network to create the cross-chain request;

and the contract callback unit 813 is used for enabling the source node to call the intelligent contract task callback method in response to the cross-chain message so as to return the data to be processed to the intelligent contract.

Optionally, the blockchain transaction performed by each source node is as follows:

transacting through the identified first blockchain; alternatively, the first and second electrodes may be,

through the first blockchain transaction generated in the consensus blockchain transaction.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging 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 forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

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 computer storage media 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, 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 media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

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 an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may 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 may also be possible or may be advantageous.

The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification 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 and 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, such 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 herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims

1. A cross-chain interaction method comprises the following steps:

at least one source node in a source block chain network initiates a cross-chain request to a destination block chain network so that each destination node in the destination block chain network obtains the cross-chain request respectively, wherein the source block chain network and the destination block chain network are block chain subnets managed by a block chain main network, and a main network node in the block chain main network and a subnet node in the block chain subnets managed by the block chain main network are deployed in the same node device;

2. The method of claim 1, further comprising:

the source node signs a block chain message to be transmitted by adopting a self node private key, encrypts the block chain message to be transmitted and the signature of the block chain message by adopting a symmetric key, respectively encrypts the symmetric key by adopting a node public key of each destination node, and adds the encrypted signature, the encrypted block chain message and each encrypted symmetric key to the cross-chain request;

and each destination node decrypts the symmetric key encrypted by the self node public key in the cross-link request through the self node private key, decrypts the encrypted block chain message and the signature through the symmetric key obtained by decryption, and returns the cross-link message to the source block chain network according to the block chain message obtained by decryption under the condition that the signature verification passes through the node public key of the source node.

3. The method of claim 1, wherein the cross-link message is returned to the source blockchain network by each destination node in a unicast or broadcast manner.

4. The method of claim 1, wherein the blockchain master network maintains node identity information of each source node in the active blockchain network, and the cross-chain request comprises identity information for characterizing the node identity of the source node initiating the cross-chain request; the method further comprises the following steps:

and each destination node inquires the node identity information of the source node initiating the cross-chain request from the block chain main network respectively to verify the identity information, and responds to the cross-chain request under the condition that the verification is passed.

5. The method of claim 1, wherein the blockchain master network maintains node identity information of each destination node in the destination blockchain network, and the cross-chain message includes identity information for characterizing the node identity of the destination node returning the cross-chain message; the method further comprises the following steps:

and each source node inquires the master network of the block chain and returns the node identity information of the target node of the cross-chain message so as to verify the identity information, and the block chain transaction is generated according to the cross-chain message passing the verification.

6. The method of claim 4 or 5, wherein the master and sub-network nodes on the node device share a blockchain plug running on the node device; any block chain node queries node identity information of any subnet node from the block chain main network, and the node identity information comprises the following steps:

and the any blockchain node reads the node identity information of any subnet node maintained by the main network node through a blockchain plug-in shared by the main network node deployed on the node equipment to which the blockchain node belongs.

7. The method according to claim 4 or 5, wherein 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; any block chain node queries node identity information of any subnet node from the block chain main network, and the node identity information comprises the following steps:

and any block chain node reads the node identity information of any subnet node maintained by the subnet management contract.

8. The method according to claim 4 or 5, wherein the identification information of any subnet node comprises a node identifier declared by any subnet node and a subnet identifier of a blockchain subnet to which the any subnet node belongs; any block chain node queries node identity information of any subnet node from the block chain main network, and the node identity information comprises the following steps:

and any block chain node inquires whether the node identifier and the subnet identifier declared by any subnet node are matched with each other from the block chain main network.

9. The method according to claim 4 or 5, wherein the identification information of any sub-network node comprises a signature generated by any sub-network node based on a node private key of the sub-network node; any block chain node queries node identity information of any subnet node from the block chain main network to verify the identity information, and the verifying comprises the following steps:

and any block chain node inquires a node public key of any subnet node from the block chain main network, and the signature is verified by adopting the node public key.

10. The method of claim 1 or 5, further comprising:

and each source node performs Byzantine fault tolerance verification on the acquired cross-chain message according to the message quantity of the cross-chain message acquired by the source node and the total node quantity of the target node in the target block chain network, and generates the block chain transaction according to the cross-chain message passing the verification.

11. The method of claim 10, the blockchain master network maintaining a node inventory of destination nodes in the destination blockchain network, the method further comprising:

and each source node queries the total amount of the nodes from the block chain main network respectively.

12. The method according to claim 10, wherein the interlink message includes data to be processed, and the performing, by each source node, a byzantine fault-tolerant check on the interlink message acquired by the source node according to the number of the interlink messages acquired by the source node and the total number of nodes of the destination node in the destination block chain network includes:

and each source node performs Byzantine fault-tolerant verification on the acquired cross-chain message according to the number of the acquired cross-chain messages containing the same data to be processed and the total number of nodes of the target node in the target block chain network.

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

and each source node checks the block chain transaction synchronized with other source nodes 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 block chain transaction synchronized with other source nodes, or according to the first hash calculated 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 block chain transaction synchronized with other source nodes, and identifies the block chain transactions passing the check.

14. The method according to claim 1, wherein the source blockchain network maintains a request identifier set, a cross-chain request initiated by each source node and a cross-chain message returned by each destination node contain a same request identifier, and each source node executes the blockchain transaction respectively, including:

each source node respectively determines whether a target request identifier carried in the blockchain transaction exists in the request identifier set;

and each source node executes the block chain transaction and deletes the target request identifier from the request identifier set under the condition that the target request identifier exists in the request identifier set.

15. The method of claim 1, the cross-chain message including data to be processed, the method further comprising:

the source node calls an intelligent contract deployed in the source blockchain network to create the cross-chain request;

and the source node responds to the cross-chain message to call the intelligent contract task callback method so as to return the data to be processed to the intelligent contract.

16. The method of claim 1, wherein the blockchain transaction performed by each source node is:

17. A cross-chain interaction device, comprising:

a request initiating unit, configured to enable at least one source node in a source blockchain network to initiate a cross-chain request to a destination blockchain network, so that each destination node in the destination blockchain network obtains the cross-chain request, where the source blockchain network and the destination blockchain network are blockchain subnets managed by a blockchain master network, and a master network node in the blockchain master network and a subnet node in the blockchain subnet managed by the blockchain master network are deployed in the same node device;

18. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 1-16 by executing the executable instructions.

19. A computer-readable storage medium having stored thereon computer instructions, which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 16.