CN116032924A - Cross-chain interaction method and device, electronic equipment and storage medium - Google Patents

Abstract

The specification provides a cross-chain interaction method, a device, an electronic device and a storage medium, which are used for performing cross-chain interaction between a source blockchain network and a destination blockchain network, wherein the source blockchain network comprises a common node and at least one entrusting node, and the method comprises the following steps: all block link points in the source block chain network respectively execute cross-chain transactions to generate corresponding cross-chain request events; any node in the source blockchain network sends a corresponding cross-chain request to a target blockchain network according to the cross-chain request event under the condition that the node is determined to be a consignment node, so that the target blockchain network returns cross-chain data indicated by the cross-chain request; and under the condition that the cross-chain data is received, a corresponding callback transaction is initiated in the source blockchain network, so that each common node in the source blockchain network acquires the cross-chain data.

Description

Cross-chain interaction method and device, electronic equipment and storage medium

Technical Field

The present disclosure relates to the field of blockchain technologies, and in particular, to a method and apparatus for cross-chain interaction, an electronic device, and a storage medium.

Background

Blockchain technology builds on top of transport networks (e.g., point-to-point networks). Nodes in the blockchain network verify and store data using a chained data structure and employ a distributed node consensus algorithm to generate and update the data. In some blockchain networks, some nodes sometimes have a need to implement small-scale transactions to avoid other nodes from obtaining these transactions and their related data. A blockchain subnetwork may be further built on the blockchain subnetwork basis. Further, there may be a need for cross-chain interactions between different blockchain networks, so that nodes in the source blockchain network may initiate cross-chain interaction requests to the destination blockchain network.

However, in the related art, each common node in the source blockchain network sends a cross-chain request to the destination blockchain network in response to the cross-chain transaction, resulting in a large data transmission amount and heavy node load.

Disclosure of Invention

To overcome the problems in the related art, the present specification provides a cross-chain interaction method, apparatus, electronic device, and storage medium.

According to a first aspect of embodiments of the present disclosure, there is provided a cross-chain interaction method for performing cross-chain interaction between a source blockchain network and a destination blockchain network, where the source blockchain network includes a normal node and at least one delegate node, the method including:

All block link points in the source block chain network respectively execute cross-chain transactions to generate corresponding cross-chain request events;

any node in the source blockchain network sends a corresponding cross-chain request to a target blockchain network according to the cross-chain request event under the condition that the node is determined to be a consignment node, so that the target blockchain network returns cross-chain data indicated by the cross-chain request; and under the condition that the cross-chain data is received, a corresponding callback transaction is initiated in the source blockchain network, so that each common node in the source blockchain network acquires the cross-chain data.

According to a second aspect of embodiments of the present specification, there is provided a cross-chain interaction device for cross-chain interaction between a source blockchain network and a destination blockchain network, the source blockchain network including a normal node and at least one delegate node, the device comprising:

the generation unit is used for respectively executing cross-chain transactions on all block chain link points in the source block chain network to generate corresponding cross-chain request events;

the source block chain network is used for providing a source block chain network with a source block chain request event, wherein the source block chain network is used for providing a source block chain network with a source block chain, and the source block chain network is used for providing a source block chain network with a source block chain; and under the condition that the cross-chain data is received, a corresponding callback transaction is initiated in the source blockchain network, so that each common node in the source blockchain network acquires the cross-chain data.

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

a processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of the method of the first aspect described above.

According to a fourth aspect of embodiments of the present description, there is provided a computer-readable storage medium having stored thereon executable instructions; wherein the instructions, when executed by a processor, implement the steps of the method of the first aspect described above.

In the embodiment of the specification, the delegation node and the common node are divided in the source blockchain network, so that the subsequent cross-chain request is sent by the delegation node; and the delegation node receives the cross-link data returned by the target block chain network, so that each common node is prevented from sending a cross-link request to the target block chain network and receiving the returned cross-link data, the data transmission quantity between the source block chain network and the target block chain network is effectively reduced, and the workload of the common node is reduced.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the specification and together with the description, serve to explain the principles of the specification.

FIG. 1 is a schematic diagram of a block chain network architecture according to an exemplary embodiment of the present disclosure;

FIG. 2 is an interactive schematic diagram of a cross-subnet communication provided in an exemplary embodiment of the present disclosure;

FIG. 3 is a flowchart of a cross-chain interaction method provided by an exemplary embodiment of the present disclosure;

FIG. 4 is a schematic diagram of a delegated node provided by an exemplary embodiment of the present specification;

FIG. 5 is a schematic diagram of an initiate replacement proposal provided by an exemplary embodiment of the present description;

FIG. 6 is a schematic diagram of a destination blockchain network configuration delegation node provided in an exemplary embodiment of the present disclosure;

FIG. 7 is a schematic block diagram of an electronic device according to an exemplary embodiment of the present disclosure;

fig. 8 is a block diagram of a cross-chain interaction device according to an exemplary embodiment of the present disclosure.

Detailed Description

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

It should be noted that: in other embodiments, the steps of the corresponding method are not necessarily performed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. Furthermore, individual steps described in this specification, in other embodiments, may be described as being split into multiple steps; while various steps described in this specification may be combined into a single step in other embodiments. It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

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

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

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

Taking the example of user Bob, bob may send a transaction containing information to create an intelligent contract to the ethernet network, the EVM of node 1 may execute the transaction and generate the corresponding contract instance. After agreement is reached between nodes through the consensus mechanism, this contract is successfully created and can be invoked in a subsequent process. After the contract is created, a contract account corresponding to the intelligent contract appears on the blockchain, and the contract account is stored with a specific address. The behavior of the smart contract is controlled by the contract code. In other words, the smart contract causes a virtual account to be generated on the blockchain that includes a contract code and an account store (Storage).

Taking the ethernet as an example, bob sends a transaction for invoking a smart contract to the ethernet network, the EVM of a node may execute the transaction and generate the corresponding contract instance. After invoking the smart contract, the value of the balance may change. Subsequently, a client may view the current value of the policy through a blockchain node. The intelligent contract is independently executed at each node in the blockchain network in a specified mode, all execution records and data are stored on the blockchain, so that when the transaction is completed, transaction credentials which cannot be tampered and cannot be lost are stored on the blockchain.

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

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

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

Event：

[topic][data]

[topic][data]

......

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

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

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

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

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

The process of quickly constructing the blockchain sub-network based on the blockchain main network is as follows: each block link point in the block chain main network respectively acquires a transaction for constructing a block chain sub-network, wherein the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information of node members participating in constructing the block chain sub-network, each block link point in the block chain main network respectively executes the transaction to permeate out the configuration information, and when the configuration information comprises the identity information of the node member corresponding to the first block link point, node equipment for deploying the first block chain node starts a second block chain node belonging to the block chain sub-network based on the creation block comprising the configuration information.

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

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

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

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

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

The identity information of the node member may include a public key of the node, or other information capable of characterizing the identity of the node, such as a node ID, which is not limited in this specification. Taking the public key as an example, each blockchain node has one or more public and private key pairs, the private key is held by the blockchain node, and the public key is disclosed and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Thus, for blockchain nodes that are desired to be node members of a blockchain subnetwork, the public keys of those blockchain nodes can be added to the transactions that constitute the blockchain subnetwork as identity information for the node members. The public-private key pair described above may be used in the process of signature verification. For example, in a consensus algorithm with a signature, such as subnet1 described above, where the message is signed with its own maintained private key, the signed message is broadcast in subnet1, and the nodeB1, nodeC1, and nodeD1 can verify the signature of the received message with the public key of nodeA1 to confirm that the message received by themselves was indeed from nodeA1 and was not tampered with.

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

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

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

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

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

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

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

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

Taking as an example the transactions that call the AddSubnet () method in the Subnet contract are performed by the nodes nodeA to nodeE on the Subnet 0. After the transaction passes the consensus, performing an AddSubNet () method by the nodeA to the nodeE respectively, and transmitting configuration information to obtain a corresponding execution result.

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

Event：

[topic:other][data]

[topic:subnet][data]

......

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

{subnet1；

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

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

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

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

}

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

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

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

As mentioned above, the first main network node and the first sub network node do not necessarily use the same identity information. Thus, in the above embodiment, the data field may contain identity information generated in advance for the nodeA1 to nodeD1, and is distinguished from the identity information of the nodeA to nodeD. Still taking nodeA and node device 1 as examples: the node device 1 may generate an creation block, deploy the nodeA1 and load the creation block by the nodeA1 if the identity information of the nodeA1 is found in the data field, or, if the nodeA finds the identity information of the nodeA1 in the data field, the nodeA triggers the node device 1 to generate the creation block, deploy the nodeA1 and load the creation block by the nodeA 1; the processing manners of nodeB to nodeD are similar and are not described in detail herein.

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

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

The node device enables deployment of a blockchain node on the node device by creating an instance of running blockchain platform code in the process. For a first master network node, creating, by a node device, a first instance in the process and running blockchain platform code from the first instance. Similarly, for a first subnet node, a second instance is created by the node device in the process described above that is distinct from the first instance and formed by the second instance running blockchain platform code. For example, a node device may first create a first instance in a process to form a first blockchain node in a blockchain master network; and when the node member corresponding to the node device wants to participate in the construction of the blockchain sub-network, a second instance can be created in the process, wherein the second instance is different from the first instance, and a second blockchain node in the blockchain sub-network is formed by the second instance. When the first instance and the second instance are located in the same process, because cross-process interaction is not involved, the deployment difficulty of the first subnet node can be reduced, and the deployment efficiency can be improved. Of course, the second instance and the first instance may also be in different processes on the node device, which is not limited in this specification; for example, a node device may create a first instance in a first process to form a first blockchain node in a blockchain master network; when the node member corresponding to the node device wishes to participate in the construction of the blockchain sub-network, a second process different from the first process may be started, and a second instance may be created in the second process, where the second instance is different from the first instance, and further the second instance forms a second blockchain node in the blockchain sub-network. In fact, each blockchain node deployed on any node device involved in the embodiments of the present disclosure is a different blockchain instance running on the any node device, the blocks generated by each blockchain node deployed on any node device are respectively stored in different stores (such as databases) on the any node device, and the stores used by each blockchain node deployed on any node device are isolated from each other.

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

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

After the creation of the sub-network is completed and the communication of the sub-network is realized based on the content, the transmission of the cross-link request can be realized, thereby meeting the cross-link interaction requirement. However, in the related art, the cross-link request is transmitted by multiple parties, and there is a problem in that the data transmission amount is large. For example, taking the embodiment shown in fig. 1 as an example, if it is assumed that the subnets 1 and 2 have a cross-link interaction requirement, each source node (such as nodeA1, nodeB1, nodeC1 and nodeD 1) generates a corresponding cross-link request event because of executing the cross-link transaction, so that each source node sends a cross-link request to each destination node (such as nodeA2, nodeB2, nodeC2 and node2) in the subnets according to the corresponding cross-link request event, resulting in huge inter-block-link data transmission amount and heavy node burden.

In view of the above, the present disclosure proposes an improved cross-link interaction method, and the following detailed description will be made with reference to the embodiments.

FIG. 3 is a flowchart of a method for cross-chain interaction between a source blockchain network and a destination blockchain network, the source blockchain network including a regular node and at least one delegate node, according to an exemplary embodiment of the present disclosure, the method may include the steps of:

Step 302, all block link points in the source block chain network execute cross-chain transactions to generate corresponding cross-chain request events.

The determination of the delegate node may be either an advance assignment or a temporary determination. Specifically, the pre-designation may refer to defining nodeA1 as a delegate node when creating the subnet1 shown in fig. 1, that is, determining the delegate node by means of an administrator initiating a confirmation delegate node transaction on the subnet1, so that after the subnet1 is through consensus, the delegate node may be approved, and then the dele node may send a cross-link request. Of course, the delegation node may be temporarily specified, for example, when a cross-link interaction is required, the user may temporarily specify the nodeA1 as the delegation node, which is not limited in this specification.

As previously described, after executing a transaction invoking 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 result of contract execution can be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in a receipt. The messaging mechanism may implement messaging through events in the receipt to trigger the blockchain node to perform the corresponding process. Then, in the case of corresponding cross-chain interactions, the corresponding smart contract transaction may also be a cross-chain transaction, thereby generating a corresponding cross-chain request event. In the related art, because the nodes in the source blockchain maintain the same "ledger" (consistency), all blockchain nodes in the source blockchain network execute the cross-chain transaction to generate corresponding cross-chain request events, and the interval duration of each blockchain node executing the cross-chain transaction depends on the efficiency of data synchronization in the blockchain. Further, each blockchain node sends a cross-chain request to the destination blockchain network according to the cross-chain request event, thereby making the data transmission huge. Therefore, the specification proposes to divide the entrusting node, so that any cross-link request is sent through the entrusting node, and the data transmission quantity is effectively reduced.

Note that, the number of the delegate nodes is not limited in the present specification, and for example, in the subnet1 shown in fig. 4, only the nodeA1 may be determined as the delegate node; it is also possible to determine nodeA1 and nodeB1 as delegate nodes, respectively; even each node in the subnet1 can be a delegated node.

It should be emphasized that, although in the embodiment shown in fig. 4, the source blockchain network and the destination blockchain network are respectively subnetworks of the main network, that is, the subnetwork 1 and the subnetwork 2 perform cross-chain interaction, the present disclosure is not limited to the subnetworks. In some embodiments, interactions between common blockchain networks may also rely on the cross-chain interaction method described in this specification, which is not limiting in this specification.

Step 304, if any node in the source blockchain network determines itself to be a delegated node, a corresponding cross-link request is sent to a destination blockchain network according to the cross-link request event, so that the destination blockchain network returns cross-link data indicated by the cross-link request; and under the condition that the cross-chain data is received, a corresponding callback transaction is initiated in the source blockchain network, so that each common node in the source blockchain network acquires the cross-chain data.

As described above, the tile link point may perform a preset process by listening to the topic of the event, in case that a predefined topic is heard, or read the related content from the data field of the corresponding event, and may perform a preset process based on the read content. So, in practice the delegation node can continue the snoop mechanism, sending the cross-chain request to the destination blockchain network in the event that the cross-chain request event is heard. However, the snoop mechanism of the block-on-snoop may have problems with untimely handling, for example: assuming nodeA1 as a delegated node, the nodeA1 monitors that the transaction corresponding to block 5 has a cross-link request event, and the cross-link request event is being processed; at this time, the block No. 6 is generated, but the nodeA1 still does not process the cross-link request event corresponding to the block No. 5, which results in untimely processing. In view of this, in order to avoid the above situation, the present specification proposes a self-checking mechanism, that is, in the case that any node in the source blockchain network determines itself as a delegated node, the node performs self-checking on transaction receipts generated by each block in order from small to large according to the block height; and each time a cross-chain request event is detected, a corresponding cross-chain request is sent to the target blockchain network according to the detected cross-chain request event. That is, the delegation node may perform self-checking on transaction receipts generated by each block in sequence from the 0 th block in order from small to large, that is, perform self-checking operations in the order of the 0 th block, the 1 st block, and the 2 nd block, and send corresponding cross-chain requests according to the detected cross-chain request event whenever the cross-chain request event is detected. For example, when the nodeA1 self-checks the transaction receipt generated by the No. 1 block, it is determined that the corresponding cross-link request event exists in the transaction receipt generated by the No. 1 block, and then the nodeA1 may send the corresponding cross-link request to the target blockchain network, and after the transaction receipt generated by the No. 1 block is processed, the entrusting node may then check the No. 2 block, and sequentially continue checking. Based on the self-checking mechanism, even if the entrusting node generates a new block when processing the cross-link request event, the problem of untimely processing and omission cannot be caused, and the cross-link request event can be ensured to be processed in a one-to-one order.

In order to ensure that the delay caused by the self-checking of the delegate node is within the preset range, the self-checking speed of the delegate node can be adaptively adjusted, for example, if the nodeA1 has corresponding blocks No. 0, no. 1, no. 2 and No. 3, but the nodeA1 only self-checks to the block No. 2, and a certain hysteresis exists, the nodeA1 can accelerate the self-checking speed at this time, so as to ensure that the hysteresis is within an acceptable range. In order to obtain the block height, the nodeA1 can poll its own block height at regular time, for example, check its own block height every 500ms, so as to adjust the corresponding self-checking speed in time. Or whether the nodeA1 is triggered by whether the block is out or not to inquire the block height of the nodeA1, namely after the block is out, the nodeA1 inquires the block height of the nodeA 1; if no block is present, nodeA1 does not query its own block height, which is not limited in this specification.

In one embodiment, to conserve storage resources, the block may not store a specific transaction receipt that stores only the corresponding transaction, and the delegation node may then generate the transaction receipt by way of executing the transaction stored in the blockchain so that the delegation node can self-check the transaction receipt. In another embodiment, the block may have a corresponding transaction receipt stored directly, and the trusted node may then self-check the transaction receipt stored in the block directly. Of course, instead of storing the transaction receipt in the block, it is also possible to store the transaction receipt under the chain, i.e. the block stores the corresponding transaction and the transaction receipt under the chain. The trusted node may then self-check the transaction receipts stored under the chain, which is not limited in this specification.

After restarting, the blockchain node may lose the corresponding message, for example, the aforementioned monitoring mechanism is taken as an example, and after monitoring the corresponding cross-link request event, nodeA1 sends the corresponding cross-link request to the target blockchain network, but assuming that the nodeA1 is restarted due to system abnormality and other reasons, the nodeA1 does not record the corresponding processing progress of itself, and cannot confirm whether the corresponding cross-link request has been sent. In view of this, the present description may further enable nodeA1 to maintain a self-checking progress on the basis of improving the listening mechanism to the self-checking mechanism. Then the delegate node updates the self-check progress to the block height of either block or the next block of either block if the self-check of the transaction receipt generated for either block is complete and the self-check result indicates that there is no cross-chain request event or that the self-checked cross-chain request event has completed processing. For example, in the case where nodeA1 is the entrusted node, when nodeA1 performs the self-checking in order from small to large according to the block height, if nodeA1 completes the No. 3 block by self-checking and completes the transmission of the cross-link request according to the cross-link request event generated by the No. 3 block, nodeA1 may update the self-checking progress to the No. 3 block or the No. 4 block, that is, indicate that nodeA1 has completed the self-checking of the No. 3 block, or indicate that the next self-checking block of nodeA1 is the No. 4 block. In particular, the self-checking progress may be stored in a local storage space of the delegate node, such as updating the corresponding block height in a database maintained locally. Based on the maintenance self-checking progress, even if the entrusted node is restarted due to an emergency, the message can be prevented from being lost, the cross-chain request event can be continuously and orderly processed, and the normal operation of the service is ensured.

In addition to restarting the delegation node in the event of an unexpected situation, the delegation node may become a disqualified node, which may not normally perform transmission of a cross-link request, so that, in order to ensure normal operation of a service, a corresponding byesting check may be initiated, that is, a normal node may also initiate a replacement proposal for the delegation node, as shown in fig. 5, and fig. 5 is a schematic diagram of a replacement proposal provided in an exemplary embodiment of the present disclosure. That is, when each ordinary node monitors the cross-link request event or determines that the cross-link data is not acquired within a preset time period after the delegate node issues the cross-link request, initiating a replacement proposal (a tracker message) for the delegate node to other ordinary nodes; any common node initiates a delegated node replacement transaction in the source blockchain network if a replacement proposal initiated by more than a preset number of common nodes is obtained. For example, in a case where the node b1 monitors the cross-link request event or determines that the cross-link data is not acquired within a preset time period after the delegate node issues the cross-link request, the node b1 may initiate a corresponding replacement proposal to other ordinary nodes, where the replacement proposal may be recorded with the ID of the delegate node, the ID of the node b1, the corresponding cross-link request ID, etc., and the replacement proposal may be initiated in the form of an under-link message, so that any ordinary node initiates a delegate node replacement transaction in the source blockchain network if a replacement proposal initiated by more than a preset number of ordinary nodes is acquired, so that the original delegate node nodeA1 may be replaced with the node b1, that is, the node b1 replaces the node a1 to become a new delegate node. Of course, the setting of the preset duration may be determined according to actual requirements, for example, 500ms, or the like, that is, in a case that the cross-link data is not acquired for more than 500ms, the replacement proposal for the delegate node may be initiated to other ordinary nodes.

The number of the delegated node replacement transactions can be not limited to one because the delegated node replacement transactions can be initiated by any common node, so that in order to save system resources, the blockchain node in the source blockchain network can execute the received first delegated node replacement transaction meeting the execution condition and ignore replacement transactions initiated by other common nodes; wherein the execution conditions include: containing replacement proposals initiated by more than a preset number of common nodes. That is, in case that the number of delegated node replacement transactions is greater than 1, the blockchain node in the source blockchain network may only execute the first delegated node replacement transaction satisfying the execution condition, thereby omitting replacement transactions initiated by other common nodes, and thus, system resources may be effectively saved. Specifically, the replacement requesting node may be performed in a predetermined order, for example, in a predetermined order nodeA1, nodeB1, nodeC1, nodeD1. If the current requesting node is nodeA1, after the requesting node exchange transaction is initiated, nodeB1 may be replaced with the wrongly generated nodeA1, and nodeB1 may be set as a new requesting node. Of course, the preset sequence can be flexibly determined according to actual requirements, and the specification is not limited to this.

The predetermined number may be determined according to a total amount of blockchain nodes, and in an embodiment, in a case that a total amount of blockchain nodes included in the source blockchain network is 3f+1, the predetermined number is f+1, where f belongs to a positive integer. For example, assuming that the total number of blockchain nodes is 22, the preset number may be 8, i.e., if a replacement proposal of 8 or more is received, a corresponding delegated node replacement request may be initiated. That is, the source blockchain network may allow 7 disqualified nodes, and accordingly, whenever a replacement proposal greater than the tolerance (7 disqualified nodes) is received, the exception of the delegate node may be confirmed, thereby initiating a corresponding delegate node replacement transaction. Based on the Bayesian detection, even if the entrusting node becomes a disliked node, the disliked entrusting node can be replaced timely, so that the normal operation of the service is ensured.

In addition to providing the delegation node in the source blockchain network, the delegation node may also be provided in the destination blockchain network, so that the source blockchain network does not need to receive the cross-link data returned by each destination node in the destination blockchain network, but only needs to receive the cross-link data returned by the delegation node in the destination blockchain network, as shown in fig. 6, fig. 6 is a schematic diagram of a destination blockchain network configuration delegation node provided in an exemplary embodiment of the present disclosure. That is, the delegate node may send a cross-chain request to each destination node in the destination blockchain network; or, in the event that a delegation node is included in the destination blockchain network, the delegation node in the source blockchain network may send a cross-chain request to the delegation node in the destination blockchain network. Of course, the delegation node in the source blockchain network needs to determine information about the delegation node in the destination blockchain network to send a corresponding cross-chain request to the delegation node in the destination blockchain network. Thus, in one embodiment, a subnet management contract may be deployed on a blockchain master network that maintains delegated node information in each blockchain subnet that is built based on the blockchain master network. Then the delegation node in the source blockchain network can read delegation node information in each blockchain subnet based on the blockchain main network set up maintained by the subnet management contract to determine delegation nodes in the destination blockchain network at this time, so that the delegation node in the source blockchain network can send a cross-chain request to the determined delegation nodes in the destination blockchain network, and then the data transmission amount between the source blockchain network and the destination blockchain network is further reduced. Specifically, when a main network node in a blockchain main network and a subnet node (for example, a source node or a destination node) in a blockchain subnet managed by the blockchain main network are deployed on the same node device, the main network node and the subnet node on the node device can share a part of blockchain plugins running on the node device, at this time, any blockchain node can query the commission node information of the blockchain network to which any subnet node belongs through the blockchain plugins, for example, the commission node information of any blockchain subnet maintained by the blockchain main network can be read through the blockchain plugins shared with the main network node deployed on the node device to which the blockchain node belongs. The blockchain plugin may be a plugin deployed in a blockchain main network and used for invoking a subnet management contract, and any blockchain node may query the delegated node information of any blockchain subnet by initiating a transaction for invoking the subnet management contract (e.g. reading a subnet state maintained by the subnet management contract) in the subnet0 through a corresponding main network node. Of course, to ensure query speed, the transactions may be transactions that do not require consensus.

It should be noted that, because the block consensus process of each destination node in the destination blockchain is not synchronous, the received cross-chain data of the delegate node may be inconsistent, in order to solve this problem, the present disclosure further proposes an anchoring of a timestamp, and specifically, the delegate node may encapsulate the corresponding first moment in the cross-chain request, so that each destination node in the destination blockchain network may determine the cross-chain data requested by the source blockchain network according to the first moment timestamp encapsulated in the cross-chain request as a reference, and finally ensure that the cross-chain data received by the delegate node is consistent.

Based on the above embodiments, the present specification divides the delegated node and the normal node in the source blockchain network, so that the subsequent cross-chain requests are sent by the delegated node; and the delegation node receives the cross-link data returned by the target block chain network, so that each common node is prevented from sending a cross-link request to the target block chain network and receiving the returned cross-link data, the data transmission quantity between the source block chain network and the target block chain network is effectively reduced, and the workload of the common node is reduced.

Corresponding to the embodiments of the aforementioned method, the present specification also provides embodiments of an apparatus, an electronic device, and a storage medium.

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

FIG. 8 is a block diagram of a cross-chain interaction device provided by an example embodiment. Referring to fig. 8, for cross-chain interaction between a source blockchain network and a destination blockchain network, the source blockchain network includes a normal node and at least one delegated node, the apparatus includes:

A generating unit 802, configured to perform a cross-chain transaction on all block link points in the source block chain network respectively to generate corresponding cross-chain request events;

a cross-link request sending unit 804, configured to send a corresponding cross-link request to a destination blockchain network according to the cross-link request event when any node in the source blockchain network determines itself to be a delegated node, so that the destination blockchain network returns cross-link data indicated by the cross-link request; and under the condition that the cross-chain data is received, a corresponding callback transaction is initiated in the source blockchain network, so that each common node in the source blockchain network acquires the cross-chain data.

Alternatively, the cross-chain request sending unit 804 is specifically configured to: under the condition that any node in the source block chain network determines itself to be a consignment node, carrying out self-checking on transaction receipts generated by all blocks in sequence from small to large according to the height of the blocks; and each time a cross-chain request event is detected, a corresponding cross-chain request is sent to the target blockchain network according to the detected cross-chain request event.

Optionally, the entrusting node maintains a self-checking progress; the apparatus further comprises:

The self-checking progress unit 806 is configured to update the self-checking progress to the block height of any block or the next block of any block when the delegate node completes self-checking of the transaction receipt generated for the any block, and the self-checking result indicates that there is no cross-chain request event or the self-checked cross-chain request event has completed processing.

Optionally, the apparatus further comprises:

a delegate node replacement unit 808, configured to initiate a replacement proposal for the delegate node to other ordinary nodes when each ordinary node monitors the cross-link request event or determines that the cross-link data is not acquired within a preset time period after the delegation node issues the cross-link request; any common node initiates a delegated node replacement transaction in the source blockchain network if a replacement proposal initiated by more than a preset number of common nodes is obtained.

Optionally, the blockchain node in the source blockchain network executes the received entrusted node replacement transaction which satisfies the execution condition for the first time, and ignores replacement transactions initiated by other common nodes; wherein the execution conditions include: containing replacement proposals initiated by more than a preset number of common nodes.

Optionally, in the case that the total amount of blockchain nodes included in the source blockchain network is 3f+1, the preset number is f+1, where f belongs to a positive integer.

Alternatively, the cross-chain request sending unit 804 is specifically configured to: the entrusting node sends a cross-link request to each destination node in a destination block chain network; or, in the case that a delegation node is included in the destination blockchain network, the delegation node in the source blockchain network sends a cross-chain request to the delegation node in the destination blockchain network.

Optionally, the source blockchain network and the destination blockchain network are blockchain subnets managed by a blockchain main network, a subnet management contract is deployed on the blockchain main network, and the subnet management contract maintains entrusted node information in each blockchain subnet built based on the blockchain main network;

the cross-link request sending unit 804 is specifically configured to: the consignment node in the source blockchain network reads consignment node information in each blockchain sub-network based on the blockchain main network maintenance of the sub-network management contract to determine consignment nodes in a target blockchain network; the delegation node in the source blockchain network sends a cross-chain request to the determined delegation node in the destination blockchain network.

For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the modules illustrated as separate components may or may not be physically separate, and the components shown as modules may or may not be physical, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present description. Those of ordinary skill in the art will understand and implement the present invention without undue burden.

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

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

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

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

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

The terminology used in the description presented herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this 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 or all possible combinations of one or more of the associated listed items.

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

The foregoing description of the preferred embodiments is provided for the purpose of illustration only, and is not intended to limit the scope of the disclosure, since any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the disclosure are intended to be included within the scope of the disclosure.

Claims (11)

1. A method of cross-chain interaction for cross-chain interaction between a source blockchain network and a destination blockchain network, the source blockchain network including a common node and at least one delegated node, the method comprising:

all block link points in the source block chain network respectively execute cross-chain transactions to generate corresponding cross-chain request events;

Any node in the source blockchain network sends a corresponding cross-chain request to a target blockchain network according to the cross-chain request event under the condition that the node is determined to be a consignment node, so that the target blockchain network returns cross-chain data indicated by the cross-chain request; and under the condition that the cross-chain data is received, a corresponding callback transaction is initiated in the source blockchain network, so that each common node in the source blockchain network acquires the cross-chain data.

2. The method of claim 1, the sending the corresponding cross-chain request to the destination blockchain network according to the cross-chain request event, comprising:

under the condition that any node in the source block chain network determines itself to be a consignment node, carrying out self-checking on transaction receipts generated by all blocks in sequence from small to large according to the height of the blocks;

and each time a cross-chain request event is detected, a corresponding cross-chain request is sent to the target blockchain network according to the detected cross-chain request event.

3. The method of claim 2, the delegated node maintaining self-checking progress; the method further comprises the steps of:

the consignment node updates the self-checking progress to the block height of any block or the next block of any block when the self-checking of the transaction receipt generated for any block is completed and the self-checking result indicates that there is no cross-chain request event or the self-checked cross-chain request event has completed processing.

4. The method of claim 1, the method further comprising:

under the condition that each common node does not acquire the cross-link data within a preset time period after monitoring the cross-link request event or determining that the delegation node sends out the cross-link request, initiating a replacement proposal for the delegation node to other common nodes;

any common node initiates a delegated node replacement transaction in the source blockchain network if a replacement proposal initiated by more than a preset number of common nodes is obtained.

5. The method of claim 4, wherein a blockchain node in the source blockchain network performs a received delegated node replacement transaction that satisfies the execution condition for the first time, and ignores replacement transactions initiated by other common nodes;

wherein the execution conditions include: containing replacement proposals initiated by more than a preset number of common nodes.

6. The method of claim 4 or 5, wherein the predetermined number is f+1, where f is a positive integer, in the case that the total amount of blockchain nodes included in the source blockchain network is 3f+1.

7. The method of claim 1, the sending a corresponding cross-chain request to a destination blockchain network, comprising:

The entrusting node sends a cross-link request to each destination node in a destination block chain network; or alternatively, the first and second heat exchangers may be,

in the case where a delegation node is included in the destination blockchain network, the delegation node in the source blockchain network sends a cross-chain request to the delegation node in the destination blockchain network.

8. The method of claim 7, the source blockchain network and the destination blockchain network being blockchain subnets managed by a blockchain master network, the blockchain master network having deployed thereon subnet management contracts that maintain delegate node information in each blockchain subnet based on the blockchain master network organization; the method for transmitting a cross-chain request to a delegation node in a destination blockchain network by a delegation node in the source blockchain network in the case that the delegation node is included in the destination blockchain network comprises the following steps:

the consignment node in the source blockchain network reads consignment node information in each blockchain sub-network based on the blockchain main network maintenance of the sub-network management contract to determine consignment nodes in a target blockchain network;

the delegation node in the source blockchain network sends a cross-chain request to the determined delegation node in the destination blockchain network.

9. A cross-chain interaction device for cross-chain interaction between a source blockchain network and a destination blockchain network, the source blockchain network including a common node and at least one delegated node, the device comprising:

the generation unit is used for respectively executing cross-chain transactions on all block chain link points in the source block chain network to generate corresponding cross-chain request events;

the source block chain network is used for providing a source block chain network with a source block chain request event, wherein the source block chain network is used for providing a source block chain network with a source block chain, and the source block chain network is used for providing a source block chain network with a source block chain; and under the condition that the cross-chain data is received, a corresponding callback transaction is initiated in the source blockchain network, so that each common node in the source blockchain network acquires the cross-chain data.

10. A computer readable storage medium having stored thereon a computer program which when executed by a processor performs the steps of the method according to any of claims 1 to 8.

11. An electronic device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the method according to any one of claims 1 to 8 when the program is executed.

Images