A cross-chain interaction method and device, electronic equipment and storage medium

Abstract

The specification provides a cross-chain interaction method and device, electronic equipment and storage medium, which are used for cross-chain interaction between a source blockchain network and a target blockchain network, the source blockchain network comprising ordinary nodes and at least one delegate node, the method comprising: all blockchain nodes in the source blockchain network respectively performing cross-chain transactions to generate corresponding cross-chain request events; any node in the source blockchain network determining itself as a delegate node and sending a corresponding cross-chain request to the target blockchain network according to the cross-chain request event, so that the target blockchain network returns cross-chain data indicated by the cross-chain request; and in the case of receiving the cross-chain data, initiating a corresponding callback transaction in the source blockchain network, so that each ordinary node in the source blockchain network obtains the cross-chain data.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and in particular to a cross-chain interaction method, device, electronic device, and storage medium. Background Technology

[0002] Blockchain technology is built on top of transmission networks (such as peer-to-peer networks). Nodes in a blockchain network use a chained data structure to verify and store data, and employ distributed node consensus algorithms to generate and update data. In some blockchain networks, certain nodes may need to implement small-scale transactions to prevent other nodes from obtaining these transactions and related data. Therefore, blockchain subnets can be built on top of the main blockchain network. Furthermore, there may be cross-chain interaction needs between different blockchain networks, allowing nodes in the source blockchain network to initiate cross-chain interaction requests to the destination blockchain network.

[0003] However, in related technologies, each ordinary node in the source blockchain network sends a cross-chain request to the destination blockchain network in response to a cross-chain transaction, resulting in a large amount of data transmission and a heavy node load. Summary of the Invention

[0004] To overcome the problems existing in related technologies, this specification provides a cross-chain interaction method, apparatus, electronic device, and storage medium.

[0005] According to a first aspect of the embodiments of this specification, a cross-chain interaction method is provided for performing cross-chain interaction between a source blockchain network and a destination blockchain network, wherein the source blockchain network includes ordinary nodes and at least one delegated node, the method comprising: All blockchain nodes in the source blockchain network execute cross-chain transactions to generate corresponding cross-chain request events; When any node in the source blockchain network determines that it is a delegating node, it sends a corresponding cross-chain request to the destination blockchain network according to the cross-chain request event, so that the destination blockchain network returns the cross-chain data indicated by the cross-chain request; and, upon receiving the cross-chain data, it initiates a corresponding callback transaction in the source blockchain network, so that each ordinary node in the source blockchain network can obtain the cross-chain data.

[0006] According to a second aspect of the embodiments of this specification, a cross-chain interaction device is provided for performing cross-chain interaction between a source blockchain network and a destination blockchain network, wherein the source blockchain network includes ordinary nodes and at least one delegated node, and the device includes: A generation unit is used for all blockchain nodes in the source blockchain network to execute cross-chain transactions to generate corresponding cross-chain request events. A cross-chain request sending unit is configured to, when any node in the source blockchain network determines itself to be a delegating node, send a corresponding cross-chain request to the destination blockchain network according to the cross-chain request event, so that the destination blockchain network returns the cross-chain data indicated by the cross-chain request; and, upon receiving the cross-chain data, initiate a corresponding callback transaction in the source blockchain network so that each ordinary node in the source blockchain network can obtain the cross-chain data.

[0007] According to a third aspect of the embodiments of this specification, an electronic device is provided, comprising: A processor; a memory for storing processor-executable instructions; wherein the processor is configured to implement the steps of the method described in the first aspect above.

[0008] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, on which executable instructions are stored; wherein, when executed by a processor, the instructions implement the steps of the method described in the first aspect.

[0009] In the embodiments of this specification, by dividing the source blockchain network into delegate nodes and ordinary nodes, all subsequent cross-chain requests are executed and sent by the delegate node; and the delegate node receives the cross-chain data returned by the destination blockchain network. This avoids each ordinary node sending cross-chain requests to the destination blockchain network and each ordinary node receiving the returned cross-chain data, effectively reducing the amount of data transmission between the source blockchain network and the destination blockchain network, and reducing the workload of ordinary nodes.

[0010] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram of the architecture of a blockchain network provided in an exemplary embodiment of this specification; Figure 2 This is an interactive schematic diagram of cross-subnet communication provided by an exemplary embodiment of this specification; Figure 3 This is a flowchart of a cross-chain interaction method provided in an exemplary embodiment of this specification; Figure 4 This is a schematic diagram of a delegate node provided in an exemplary embodiment of this specification; Figure 5This is a schematic diagram illustrating an exemplary embodiment of this specification for initiating a replacement proposal; Figure 6 This is a schematic diagram illustrating a purposeful blockchain network configuration of a delegated node, provided in an exemplary embodiment of this specification. Figure 7 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment of this specification; Figure 8 This is a block diagram of a cross-chain interaction device provided in an exemplary embodiment of this specification. Detailed Implementation

[0013] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification.

[0014] It should be noted that in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification. In some other embodiments, the methods may include more or fewer steps than those described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple 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, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from each other. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0015] After a node in a blockchain network executes a transaction that invokes a smart contract, it generates a corresponding receipt to record information related to the execution of that smart contract. This allows the user to retrieve information about the contract execution result by querying the transaction receipt. The contract execution result can be represented as an event within the receipt. The messaging mechanism can use these events to transmit messages, triggering corresponding processing by blockchain nodes. An event's structure could be, for example: Event: [topic][data] [topic][data] ...... In the example above, there can be one or more events; each event includes fields such as topic and data. Blockchain nodes can listen to the topic of an event, and if a predefined topic is detected, they can perform pre-defined processing, or read relevant content from the data field of the corresponding event, and perform pre-defined processing based on the read content.

[0016] In the event mechanism described above, it's equivalent to having a client with listening capabilities on the listening party (e.g., a user with listening needs). This client might run an SDK to implement listening functionality, allowing it to listen for events generated by the blockchain node. The blockchain node only needs to generate receipts normally. Besides the event mechanism, transaction information can be revealed in other ways. For example, listening code can be embedded in the blockchain platform code running on the blockchain node. This listening code can monitor one or more types of data, such as the transaction content of blockchain transactions, the contract status of smart contracts, and receipts generated by contracts, and send the monitored data to a predefined listening party. Because the listening code is deployed in the blockchain platform code, rather than on the listening party's client, this code-based implementation is more proactive than the event mechanism. The listening code can be added to the blockchain platform code by the developers during development, or it can be embedded by the listening party based on its own needs; this specification does not impose any restrictions on this.

[0017] One of the decentralized characteristics that distinguishes blockchain technology from traditional technologies is its distributed ledger system, where records are kept on multiple nodes, rather than a centralized system. For a blockchain system to become a robust, publicly accessible, and tamper-proof decentralized system of honest and trustworthy data records, it needs to ensure the security, clarity, and irreversibility of distributed data records in the shortest possible time. In different types of blockchain networks, consensus algorithms are typically used to maintain consistency across the nodes recording the ledger—the consensus mechanisms mentioned earlier. For example, blockchain nodes can implement block-level consensus mechanisms. After a node (e.g., a unique node) generates a block, if this block is recognized by other nodes, those nodes record the same block. As another example, blockchain nodes can implement transaction-level consensus mechanisms. After a node (e.g., a unique node) acquires a blockchain transaction, if this transaction is recognized by other nodes, each node that recognized the transaction can add it to its own latest maintained block, ultimately ensuring that all nodes produce the same latest block. A consensus mechanism is a mechanism by which blockchain nodes reach a unified consensus on block information (or block data) across the entire network, ensuring that the latest block is accurately added to the blockchain. Currently, mainstream consensus mechanisms include: Proof of Work (POW), Proof of Stake (POS), Delegated Proof of Stake (DPoS), Practical Byzantine Fault Tolerance (PBFT) algorithm, and HoneyBadgerBFT algorithm, among others.

[0018] Due to the decentralized nature of blockchain networks, all blockchain nodes maintain the same block data, which cannot meet the specific needs of some nodes. Taking a consortium blockchain as an example, all consortium members (i.e., node members within the consortium) can form a blockchain network. Each member has a corresponding blockchain node within this network and can access all transactions and related data occurring on the network through their respective nodes. However, in some cases, some consortium members may wish to complete transactions with confidentiality requirements. These members want these transactions to be notarized on the blockchain or leverage other advantages of blockchain technology, while preventing other consortium members from seeing these transactions and related data. Although these members can form a new blockchain network, similar to the one with all members, building a new blockchain network from scratch requires significant resources, and both the establishment and configuration processes are very time-consuming. The needs of consortium members are often temporary or time-sensitive, causing the newly established blockchain network to quickly become obsolete due to the disappearance of these needs, further increasing the construction cost of the aforementioned blockchain network. The needs of alliance members often change, and the alliance members corresponding to each need are often different. Therefore, whenever the alliance members change, it may be necessary to build a new blockchain network, resulting in a huge waste of resources and time.

[0019] Therefore, an existing blockchain network can be used as the main network, and subnets can be built upon this main network. In consortium blockchain scenarios like those described above, consortium members can build their own subnets based on their specific needs, even while already participating in the main network. Because subnets are built upon the main network, the resource consumption and time required for subnet construction are significantly reduced compared to building a completely independent blockchain network, resulting in extremely high flexibility.

[0020] The process of quickly building a blockchain subnet based on the blockchain mainnet is as follows: Each blockchain node in the blockchain mainnet obtains a transaction for building the blockchain subnet. The transaction contains the configuration information of the blockchain subnet. The configuration information includes the identity information of the node members participating in building the blockchain subnet. Each blockchain node in the blockchain mainnet executes the transaction to expose the configuration information. When the configuration information contains the identity information of the node members corresponding to the first blockchain node, the node device deploying the first blockchain node starts a second blockchain node belonging to the blockchain subnet based on the genesis block containing the configuration information.

[0021] Transactions for building blockchain subnets can be initiated by administrators of the main blockchain network. This means that only administrators are allowed to build blockchain subnets on top of the main blockchain network, preventing the granting of subnet creation permissions to ordinary users to avoid potential security issues. In some cases, ordinary users of the main blockchain network may also be allowed to initiate these subnet creation transactions to meet their networking needs, enabling them to quickly build blockchain subnets even when administrators are unable to initiate transactions.

[0022] by Figure 1 Taking the example shown, the main blockchain network is subnet0, which contains blockchain nodes such as nodeA, nodeB, nodeC, nodeD, and nodeE. Assume that nodeA, nodeB, nodeC, and nodeD want to establish a blockchain subnet: If nodeA is the administrator and only administrators are allowed to initiate transactions to establish a blockchain subnet, then nodeA can initiate the aforementioned transaction to subnet0. If nodeE is the administrator and only administrators are allowed to initiate transactions to establish a blockchain subnet, then nodesA through nodeD need to request nodeE to initiate the aforementioned transaction to subnet0. If nodeE is the administrator but allows ordinary users to initiate transactions to establish a blockchain subnet, then nodesA through nodeE can all initiate the aforementioned transaction to subnet0. Of course, whether it is an administrator or an ordinary user, the blockchain node that initiates the transaction to build a blockchain subnet does not necessarily participate in the blockchain subnet being built. For example, although the blockchain subnet is ultimately built by nodeA, nodeB, nodeC and nodeD, nodeE can initiate the above transaction to build the blockchain subnet to subnet0, and it is not necessarily nodeA~nodeD that initiate the transaction to build the blockchain subnet.

[0023] When building a blockchain subnet on top of the mainnet, it's easy to understand that this will create a logical hierarchical relationship between the subnet and the mainnet. For example, in... Figure 1 When building a blockchain subnet subnet1 on subnet0, as shown, subnet0 can be considered to be at the first layer and subnet1 at the second layer. Subnet0 is the parent network of subnet1, and subnet1 is a subnet of subnet0. Furthermore, blockchain subnets can also form corresponding blockchain subnets; for example, they can be built on subnet0. Figure 1Based on subnet1, another blockchain subnet, subnet3, is further built. At this point, subnet can be considered to be at the third layer. Subnet1 is the parent network of subnet3, subnet3 is a subnet of subnet1, and subnet3 is a grandchild of subnet0. Similarly, subnet3 can still build new blockchain subnets on its basis, creating a multi-level tree structure among the blockchain networks. In this specification, any blockchain network is managed by its corresponding parent network, that is, by the blockchain network that built that blockchain network. Therefore, in... Figure 1 In this tree-like blockchain network system, where the main blockchain is the root node (the lowest level) and each sub-blockchain is a node representing another node, the sub-blockchain represented by any node is managed by the blockchain network corresponding to its parent node. However, as a special case, when the main blockchain is a lower-level blockchain network, it is managed by itself. In this specification, the main blockchain can refer to a lower-level blockchain network. A lower-level blockchain network is a sub-blockchain network that is not built upon other blockchain networks; therefore, no other blockchain network besides this main blockchain can manage it. For example... Figure 1 In this context, subnet0 can be considered a subnet of the underlying blockchain network type. Subnet0 manages itself. Of course, the blockchain mainnet can also be a subnet of other blockchain networks; this specification does not impose any restrictions on this. The aforementioned blockchain network tree system achieves layer-by-layer management by having parent nodes manage their corresponding child nodes, reducing the management pressure on the blockchain mainnet while avoiding exposing the subnet information of the upper-level network to lower-level networks, thus achieving covert management of each level of the network.

[0024] After the transactions for establishing a blockchain subnet are sent to the main blockchain network, they are consensus-reached by the consensus nodes within the main network. Once consensus is reached, each main network node executes the transaction to complete the establishment of the blockchain subnet. The consensus process depends on the consensus mechanism employed, such as any of the consensus mechanisms described above; this specification does not impose any restrictions on this.

[0025] By including configuration information in the transactions for building the blockchain subnet, this information can be used to configure the subnet to meet networking requirements. For example, by including node member identity information in the configuration information, it is possible to specify which blockchain nodes will be included in the subnet.

[0026] The identity information of node members may include the node's public key, or other information that can characterize the node's identity, such as the node ID. This specification does not impose any restrictions on this. Taking the public key as an example, each blockchain node has one or more corresponding public-private key pairs. The blockchain node holds the private key, while the public key is publicly available and uniquely corresponds to that private key. Therefore, the identity of the corresponding blockchain node can be represented by the public key. Thus, for blockchain nodes that wish to become members of a blockchain subnet, their public keys can be added to the aforementioned transactions for building the blockchain subnet, serving as the identity information of the node members. The aforementioned public-private key pairs can be used in the signature verification process. For example, in a consensus algorithm using signatures, such as subnet1, nodeA1 signs the message using its own private key and broadcasts the signed message in subnet1. NodeB1, nodeC1, and nodeD1 can use nodeA1's public key to sign and verify the received message, confirming that the message they received indeed came from nodeA1 and has not been tampered with.

[0027] The first mainnet node can be a blockchain node on the mainnet that belongs to the node members indicated by the configuration information. When building a blockchain subnet, the first mainnet node does not directly participate in building the blockchain subnet or become its node member. Instead, the node device used to deploy the first mainnet node needs to generate the first subnet node, and the first subnet node becomes a node member in the blockchain subnet. The first mainnet node and the first subnet node correspond to the same blockchain member, such as the same consortium blockchain member in a consortium blockchain scenario. However, the first mainnet node belongs to the mainnet of the blockchain, while the first subnet node belongs to a subnet. This allows the blockchain member to participate in transactions on both the mainnet and the subnet. Furthermore, since the mainnet and the subnet are two independent blockchain networks, the blocks generated by the first mainnet node and the blocks generated by the first subnet node are stored in different storage locations on the node devices (such as databases). This achieves mutual isolation between the storage used by the first mainnet node and the first subnet node. Therefore, the data generated by the subnet is only synchronized among the node members of the subnet, preventing blockchain members who only participate in the mainnet from accessing the data generated on the subnet. This achieves data isolation between the mainnet and the subnet, satisfying the transaction needs of some blockchain members (i.e., those participating in the subnet).

[0028] It is evident that the first mainnet node and the first subnet node are logically distinct blockchain nodes. From a physical device perspective, this means that the node devices deploying the first mainnet node and the first subnet node are simultaneously participating in both the blockchain mainnet and the blockchain subnet. Because the blockchain mainnet and the blockchain subnet are independent of each other, their identity systems are also independent. Therefore, even if the first mainnet node and the first subnet node could use the exact same public key, they should still be considered different blockchain nodes. For example, in... Figure 1 In this example, nodeA in subnet0 is equivalent to the first mainnet node, while the node device deploying nodeA generates nodeA1 belonging to subnet1, which is equivalent to the first subnet node. Therefore, since the identity systems are independent, even if the public key used by the first subnet node differs from that of the first mainnet node, it does not affect the implementation of the scheme described in this specification.

[0029] Of course, the node members of a blockchain subnet are not necessarily only some of the node members of the main blockchain. In some cases, the node members of a blockchain subnet can be completely identical to those of the main blockchain. In this case, all blockchain members can access data from both the main blockchain and the blockchain subnet. However, the data generated by the main blockchain and the blockchain subnet can still be isolated from each other. For example, one type of business can be implemented on the main blockchain and another type of business can be implemented on the blockchain subnet, thus ensuring that the business data generated by these two types of business are isolated from each other.

[0030] In addition to the node member identity information mentioned above, the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the blockchain subnet administrator, and attribute configurations for the blockchain platform code, etc., which are not limited in this specification. The network identifier is used to uniquely identify the blockchain subnet; therefore, the network identifier of the blockchain subnet should be distinct from the blockchain mainnet and other blockchain subnets built on the blockchain mainnet. The identity information of the blockchain subnet administrator may, for example, be the public key of the node member acting as the administrator; the administrators of the blockchain mainnet and the blockchain subnet may be the same or different.

[0031] One advantage of building blockchain subnets via the mainnet is that since the first mainnet node is already deployed on the node device that generates the first subnet node, the blockchain platform code used by the first mainnet node can be reused on the first subnet node, eliminating the need for repeated deployment of the blockchain platform code and greatly improving the efficiency of building the blockchain subnet. Therefore, if the configuration information does not include attribute configurations for the blockchain platform code, the first subnet node can reuse the attribute configurations used on the first mainnet node; if the configuration information includes attribute configurations for the blockchain platform code, the first subnet node can adopt those attribute configurations, making the attribute configurations used by the first subnet node independent of and not limited by the attribute configurations of the first mainnet node. Attribute configurations for the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc., but this specification does not impose any restrictions on these.

[0032] Transactions for building a blockchain subnet include transactions that invoke contracts. These transactions may specify the address of the invoked smart contract, the method of invocation, and the parameters passed in. For example, the invoked contract may be the aforementioned genesis contract or system contract, the invoked method may be the method for building a blockchain subnet, and the passed parameters may include the aforementioned configuration information. In one embodiment, the transaction may include the following information: From: Administrator To: Subnet method: AddSubnet(string) string:genesis The `from` field contains information about the initiator of the transaction, such as `Administrator` indicating that the initiator is an administrator; the `to` field contains the address of the smart contract being called, such as the address of the Subnet contract; the `method` field contains the method being called, such as `AddSubnet(string)` in the Subnet contract, where `string` is a parameter in the `AddSubnet()` method. In the example above, `genesis` represents the value of this parameter, which is the aforementioned configuration information.

[0033] Taking the transactions executed by nodes nodeA to nodeE on Subnet0, which call the AddSubnet() method in the Subnet contract, as an example, after the transaction passes consensus, nodes A to E each execute the AddSubnet() method, passing in the configuration information, and obtain the corresponding execution results.

[0034] The execution result of the contract can include the configuration information. This result can be contained in the receipt mentioned above, which may include events related to the execution of the AddSubnet() method, i.e., networking events. The topic of a networking event can contain a predefined networking event identifier to distinguish it from other events. For example, in an event related to the execution of the AddSubnet() method, the topic content is the keyword "subnet," and this keyword is different from the topics in events generated by other methods. Then, by listening to the topics contained in each event in the generated receipt, nodes A through E can determine that they have listened to an event related to the execution of the AddSubnet() method, i.e., a networking event, if they listen to a topic containing the keyword "subnet." For example, the events in the receipt are as follows: Event: [topic:other][data] [topic:subnet][data] ...... Therefore, when nodes A through E detect the first event, since its topic content is "other," they determine that the event is unrelated to the `AddSubnet()` method. Similarly, when nodes A through E detect the second event, since its topic content is "subnet," they determine that the event is related to the `AddSubnet()` method and then read the corresponding `data` field. This `data` field contains the aforementioned configuration information. Taking the configuration information including the public keys of the blockchain subnet's node members as an example, the content of the `data` field might include: {subnet1; The public key of nodeA, the IP address of nodeA, the port number of nodeA, etc.; The public key of nodeB, the IP address of nodeB, the port number of nodeB, etc.; The public key of nodeC, the IP address of nodeC, the port number of nodeC, etc.; The public key of nodeD, the IP address of nodeD, the port number of nodeD, etc.; } Here, subnet1 is the network identifier of the blockchain subnet to be created. Each blockchain node in the mainnet can record the network identifiers of all blockchain subnets already created on that mainnet, or other information related to these subnets. This information can be maintained, for example, in the aforementioned Subnet contract, specifically corresponding to the values ​​of one or more contract states contained within that Subnet contract. Then, nodes A through E can determine whether subnet1 already exists based on the recorded network identifiers of all created blockchain subnets. If it doesn't exist, it means subnet1 is the new blockchain subnet to be created; if it does exist, it means subnet1 already exists.

[0035] In addition to using the network identifier of the new blockchain subnet to be created, a predefined new network identifier can also be used. This new network identifier indicates that the corresponding networking event is used to form a new blockchain subnet. For example, subnet1 can be replaced with newsubnet, which is a predefined new network identifier. When nodeA to nodeE recognize that the data field contains newsubnet, they can determine that the event containing newsubnet is a networking event and a new blockchain subnet needs to be created.

[0036] Besides the network identifier subnet1, the aforementioned data field also contains identity information of each node member. The node device deploying the first mainnet node can listen to the generated receipts, and if it detects the network formation event and the content of the event indicates that the first mainnet node belongs to that node member, the node device deploying the first mainnet node will obtain the configuration information or genesis block contained in the network formation event. For example, if nodeA~nodeE determine that subnet1 is a newly formed blockchain subnet, they will further identify the identity information of the node members contained in the data field to determine their own processing method. For example, nodes A through D will find that their data field contains their own identity information, such as public key, IP address, and port number. Assuming nodes A through D are deployed on nodes 1 through 4 respectively, taking node A and node 1 as an example: node A will trigger node 1, causing node 1 to obtain configuration information from the data field based on the aforementioned message mechanism and generate a genesis block containing this configuration information. Node 1 will then deploy node A1 locally, and node A1 will load the generated genesis block, thus becoming a node member in subnet 1. Similarly, node B will trigger node 2 to generate node B1, node C will trigger node 3 to generate node C1, and node D will trigger node 4 to generate node D1. Furthermore, node E will find that the identity information contained in its data field does not match its own. Assuming node E is deployed on node 5, then node 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate a node in subnet 1.

[0037] As mentioned earlier, the first mainnet node and the first subnet node do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may contain identity information pre-generated for nodeA1 to nodeD1, and be different from the identity information of nodeA to nodeD. Taking nodeA and node device 1 as an example: if node device 1 finds the identity information of nodeA1 in the data field, it can generate a genesis block, deploy nodeA1, and have nodeA1 load the genesis block; or, if nodeA finds the identity information of nodeA1 in the data field, then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and have nodeA1 load the genesis block; the processing of nodeB to nodeD is similar, and will not be described in detail here.

[0038] In addition to configuration information, the execution result of a contract can include a genesis block. In other words, besides including configuration information in the data field, a genesis block containing configuration information can also be generated directly during the execution of the contract call, thus including the genesis block in the data field. For the aforementioned nodes A to D, the corresponding node devices 1 to 4 can directly obtain the genesis block from the data field through the message mechanism without having to generate it themselves, which can improve the deployment efficiency of nodes A1 to D1.

[0039] In this specification, transactions for building a blockchain subnet do not necessarily involve calling smart contracts. This allows blockchain networks that do not support smart contracts to implement the technical solutions described herein, thereby enabling the rapid creation of blockchain subnets based on the main blockchain network. For example, a set of network transaction type identifiers can be predefined. When a transaction contains this network transaction type identifier, it indicates that the transaction is used to build a new blockchain subnet, i.e., the transaction is for building a blockchain subnet. The blockchain platform code can contain related processing logic for assembling the blockchain subnet. When the first mainnet node running this blockchain platform code executes a transaction, if it finds that the transaction contains the aforementioned network transaction type identifier, and the first mainnet node belongs to the node member indicated by the configuration information in the transaction, it can trigger the node device deploying the first mainnet node to generate a genesis block containing the configuration information and start the first subnet node based on the aforementioned processing logic. The first subnet node then loads the genesis block to form a blockchain node in the blockchain subnet.

[0040] A node device deploys a blockchain node by creating an instance running the blockchain platform code within this process. For the first mainnet node, the node device creates a first instance within the aforementioned process, and this first instance runs the blockchain platform code. Similarly, for the first subnet node, the node device creates a second instance, distinct from the first instance, within the aforementioned process, and this second instance runs the blockchain platform code. For example, a node device can first create a first instance within the process to form the first blockchain node in the mainnet; when a node member corresponding to that device wishes to participate in building a blockchain subnet, a second instance can be created within the aforementioned process. This second instance, distinct from the first instance, forms the second blockchain node in the subnet. When the first and second instances reside within the same process, since cross-process interaction is not involved, the deployment difficulty of the first subnet node can be reduced, and deployment efficiency improved. Of course, the second instance may reside in a different process on the node device than the first instance, and this specification does not limit this. For example, the node device may create the first instance in the first process to form the first blockchain node in the main network. When a node member corresponding to the node device wishes to participate in building a blockchain subnet, it may start a second process different from the first process and create a second instance in the second process. This second instance is different from the first instance, and thus forms the second blockchain node in the blockchain subnet. In fact, in the embodiments of this specification, each blockchain node deployed on any node device is a different blockchain instance running on that node device. The blocks generated by each blockchain node deployed on any node device are stored in different storage (e.g., a database) on that node device, and the storage used by each blockchain node deployed on any node device is isolated from each other.

[0041] Using the methods described above, blockchain subnets can be created on the mainnet of the blockchain. Figure 1For example, subnet0 originally contains nodes A through E. Subnet1 can be built on top of subnet0, containing nodes A1 through D1, with nodes A and A1, B and B1, C and C1, and D and D1 deployed on the same node device. Similarly, subnet2 or more blockchain subnets can be built on subnet0, where subnet2 contains nodes A2, B2, C2, and E2, with nodes A and A1, A2, B and B1, B2, C and C1, D and D1, and E and E2 deployed on the same node device. Furthermore, subnet1, subnet2, etc. can be used as the main blockchain network, and further blockchain subnets can be built on this basis. For example, a blockchain subnet3 can be built on the basis of subnet1. The process is similar to the construction of subnet1 or subnet2, except that the main blockchain network is replaced by the blockchain subnet1. It will not be elaborated here. Finally, subnet3 contains nodeA3, nodeB3, and nodeC3, such that nodeA is deployed on the same node device as nodeA1, nodeA2, and nodeA3, nodeB is deployed on the same node device as nodeB1, nodeB2, and nodeB3, and nodeC is deployed on the same node device as nodeC1, nodeC2, and nodeC3.

[0042] Cross-chain interaction needs may exist between different blockchain mainnets, as well as between different blockchain subnets established in the above manner. For specific details on cross-subnet communication, please refer to... Figure 2 , Figure 2This is an exemplary embodiment of the diagram illustrating cross-subnet communication. Since the nodes of the mainnet are interconnected, cross-subnet communication can rely on the mainnet, meaning it is achieved through the mainnet's network. Specifically, when the cross-chain interaction method described in this specification is applied to two blockchain subnets managed by the blockchain mainnet, any node in subnet1 can encapsulate the network identifier of the destination blockchain network subnet2 in the cross-chain request. By invoking a P2P plugin deployed locally on the node device and shared with the mainnet nodes in subnet0, the cross-chain request is broadcast through the network connection link of subnet0 to the P2P plugins running on each node device with deployed mainnet nodes. In one embodiment, if nodeA1 in subnet1 issues a cross-chain request through the P2P plugin on node device 1, then other node devices 2-5 deployed with mainnet nodes will all receive the cross-chain request. For example, after receiving the cross-chain request, the P2P plugin on node device 5 will determine whether node device 5 has a blockchain node in the blockchain network corresponding to the network identifier carried in the cross-chain request. Obviously, nodeE2 in subnet2 is deployed on node device 5. Therefore, the P2P plugin on node device 5 will further forward the cross-chain request to nodeE2 based on the network identifier. After receiving the cross-chain request, the P2P plugin on node device 4 will also forward it based on the network identifier it carries. However, since node device 4 does not have a blockchain node in subnet2 deployed locally, node device 4 will not retain the cross-chain request, but will further forward the cross-chain request to other node devices deployed with mainnet nodes.In addition, any node in subnet1 can encapsulate not only the network identifier in the cross-chain request, but also the identity information of any node in the target blockchain network, such as node ID and node public key. This allows the P2P plugin to directly send the cross-chain request to the node device specified by the node identity information carried in the cross-chain request, instead of broadcasting it to the node device to which each mainnet node belongs, in a peer-to-peer communication manner. For example, nodeD1 in subnet1 can encapsulate the identity information of nodeE2 in the cross-chain request and call the P2P plugin running locally on node device 4. The P2P plugin can then send the cross-chain request in unicast form to node device 5, which simultaneously deploys nodeE2 in subnet2 and nodeE in subnet0, based on the identity information of nodeE2. After receiving the cross-chain request, the P2P plugin on node device 5 can forward the cross-chain request to nodeE2 either by using the network identifier carried in the cross-chain request or directly by using the identity information of nodeE2 carried in the cross-chain request.

[0043] After the subnet is created and cross-subnet communication is established based on the above, cross-chain requests can be sent, thus meeting the needs of cross-chain interaction. However, in related technologies, cross-chain requests are sent by multiple parties, resulting in a large amount of data transmission. For example, with... Figure 1 Taking the illustrated embodiment as an example, if it is assumed that there is a cross-chain interaction requirement between subnet1 and subnet2, each source node (such as nodeA1, nodeB1, nodeC1, and nodeD1) will generate a corresponding cross-chain request event because it executes a cross-chain transaction. As a result, each source node will send cross-chain requests to each destination node (such as nodeA2, nodeB2, nodeC2, and nodeE2) in subnet2 according to the corresponding cross-chain request event, resulting in a huge amount of data transmission between blockchain subnets and a heavy burden on the nodes.

[0044] In view of this, in order to solve the above problems, this specification proposes an improved cross-chain interaction method, which will be described in detail below with reference to the embodiments.

[0045] Figure 3 This is a flowchart illustrating an exemplary embodiment of a cross-chain interaction method provided in this specification. The method is used to perform cross-chain interaction between a source blockchain network and a destination blockchain network. The source blockchain network includes ordinary nodes and at least one delegated node. The method may include the following steps: Step 302: All blockchain nodes in the source blockchain network execute cross-chain transactions to generate corresponding cross-chain request events.

[0046] The delegate node can be determined in advance or temporarily. Specifically, specifying in advance can refer to determining it during the creation process, such as... Figure 1 In the case of subnet1, nodeA1 is defined as the delegate node. This means the administrator initiates a confirmation transaction on subnet1 to determine the delegate node. Once subnet1 achieves consensus, the delegate node is recognized and can then send cross-chain requests. Of course, the delegate node can also be temporarily designated. For example, if cross-chain interaction is required, the user can temporarily designate nodeA1 as the delegate node. This specification does not impose any restrictions on this.

[0047] As mentioned earlier, after a node in a blockchain network executes a transaction that invokes a smart contract, it generates a corresponding receipt to record information related to the execution of that smart contract. This allows the querying of the transaction receipt to obtain information about the contract execution result. The contract execution result can be represented as an event in the receipt. The messaging mechanism can use these events to transmit messages, triggering corresponding processing by blockchain nodes. Therefore, in the case of cross-chain interaction, the smart contract transaction can also be a cross-chain transaction, generating a corresponding cross-chain request event. However, in related technologies, because each node in the source blockchain maintains the same "ledger" (consistency), all blockchain nodes in the source blockchain network will execute the cross-chain transaction to generate the corresponding cross-chain request event. The interval between each blockchain node executing the cross-chain transaction depends on the efficiency of data synchronization in the blockchain. Furthermore, each blockchain node sends a cross-chain request to the destination blockchain network based on this cross-chain request event, resulting in a large data transmission volume. Therefore, this specification proposes the division of delegate nodes, so that any cross-chain request is sent through a delegate node, effectively reducing the data transmission volume.

[0048] It should be noted that this manual does not limit the number of delegated nodes, for example, in Figure 4 In the subnet1 shown, only nodeA1 can be designated as a delegate node; nodeA1 and nodeB1 can be designated as delegate nodes separately; or every node in subnet1 can be a delegate node.

[0049] It needs to be emphasized that, although in Figure 4 In the illustrated embodiment, the source blockchain network and the destination blockchain network are subnets of the mainnet, i.e., subnet1 and subnet2, respectively, and cross-chain interaction occurs between them. However, this specification is not limited to interactions between subnets. In some embodiments, interactions between ordinary blockchain networks may also rely on the cross-chain interaction method described in this specification, and this specification does not impose any limitations on this.

[0050] Step 304: When any node in the source blockchain network determines that it is a delegating node, it sends a corresponding cross-chain request to the destination blockchain network according to the cross-chain request event, so that the destination blockchain network returns the cross-chain data indicated by the cross-chain request; and, upon receiving the cross-chain data, it initiates a corresponding callback transaction in the source blockchain network, so that each ordinary node in the source blockchain network can obtain the cross-chain data.

[0051] As mentioned earlier, blockchain nodes can listen to event topics to execute predefined processing when a predefined topic is detected, or read relevant content from the corresponding event's data field and execute predefined processing based on the read content. Therefore, delegated nodes can effectively continue this listening mechanism to send cross-chain requests to the target blockchain network when a cross-chain request event is detected. However, the immediate listening mechanism upon block formation may have issues with delayed processing. For example, suppose nodeA1 is a delegated node that detects a cross-chain request event for the transaction corresponding to block 5 and is currently processing it. At this time, block 6 is generated, but nodeA1 has not yet completed processing the cross-chain request event corresponding to block 5, resulting in delayed processing. In view of this, to avoid the aforementioned situation, this specification proposes a self-checking mechanism. That is, any node in the source blockchain network, upon determining itself to be a delegating node, performs a self-check on the transaction receipts generated by each block in ascending order of block height. Whenever a cross-chain request event is detected, the node sends a corresponding cross-chain request to the destination blockchain network based on that event. In other words, the delegating node can perform a self-check on the transaction receipts generated by each block in ascending order, starting from block 0, i.e., performing the self-check operation in the order of block 0, block 1, block 2. Whenever a cross-chain request event is detected, the node sends a corresponding cross-chain request. For example, when nodeA1 detects a transaction receipt generated by block 1 and determines that a corresponding cross-chain request event exists in the transaction receipt generated by block 1, nodeA1 can send the corresponding cross-chain request to the destination blockchain network. After processing the transaction receipt generated by block 1, the delegating node can then check block 2, and so on. Based on this self-checking mechanism, even if a new block is generated while the delegated node is processing a cross-chain request event, the aforementioned problems of untimely or missed processing will not occur, ensuring that cross-chain request events can be processed in an orderly manner.

[0052] To ensure that the latency caused by the delegated node's self-check is within a preset range, the speed of the delegated node's self-check can be adaptively adjusted. For example, suppose nodeA1 has corresponding blocks 0, 1, 2, and 3, but nodeA1 has only self-checked up to block 2, resulting in a certain lag. In this case, nodeA1 can speed up its self-check to ensure that the lag is within an acceptable range. To obtain the block height, nodeA1 can periodically poll its own block height, such as checking its own block height every 500ms, thus adjusting the corresponding self-check speed in a timely manner. Alternatively, whether nodeA1 queries its own block height can be triggered by whether a block has been produced; that is, after a block is produced, nodeA1 queries its own block height; if no block has been produced, nodeA1 does not query its own block height. This specification does not impose any restrictions on this.

[0053] In one embodiment, to conserve storage resources, the block may not store specific transaction receipts, but only the corresponding transaction. In this case, the delegating node can generate the transaction receipt by executing the transactions stored in the blockchain, allowing the delegating node to self-check the transaction receipt. In another embodiment, the block may directly store the corresponding transaction receipt, allowing the delegating node to directly self-check the transaction receipt stored in the block. Of course, besides storing the transaction receipt in the block, it can also be stored off-chain; that is, the block stores the corresponding transaction, while the off-chain storage stores the corresponding transaction receipt. In this case, the delegating node can self-check the off-chain stored transaction receipt. This specification does not impose any limitations on this approach.

[0054] After a blockchain node restarts, it may lose corresponding messages. Taking the previously described listening mechanism as an example, after nodeA1 listens for a corresponding cross-chain request event, it will send the corresponding cross-chain request to the target blockchain network. However, if nodeA1 restarts due to system abnormalities or other reasons, it will not record its own processing progress and cannot confirm whether it has sent the corresponding cross-chain request. In view of this, this specification, based on improving the listening mechanism into a self-checking mechanism, further allows nodeA1 to maintain self-check progress. Then, when the delegated node completes the self-check of the transaction receipt generated for any block, and the self-check result shows that there is no cross-chain request event or the detected cross-chain request event has been processed, it updates the self-check progress to the block height of that block or the next block of that block. For example, when nodeA1 is a delegated node, and nodeA1 performs self-checks in ascending order of block height, if nodeA1 completes the self-check of block 3 and sends the cross-chain request based on the cross-chain request event generated by block 3, then nodeA1 can update its self-check progress to block 3 or block 4. This indicates that nodeA1 has completed the self-check of block 3, or that nodeA1's next self-check block is block 4. Specifically, the self-check progress can be stored in the delegated node's local storage space, such as updating the corresponding block height in its locally maintained database. Based on the maintained self-check progress, it can be ensured that even if the delegated node restarts due to unforeseen circumstances, messages will not be lost, and cross-chain request events can continue to be processed in an orderly manner, ensuring the normal operation of the service.

[0055] Besides the unexpected restart of the delegate node mentioned above, the delegate node may also become a malicious node, preventing the normal sending of cross-chain requests. Therefore, to ensure the normal operation of the service, a corresponding Byzantine check can be initiated; that is, ordinary nodes can also initiate a proposal to replace the delegate node, such as... Figure 5 As shown, Figure 5This is a schematic diagram of a replacement proposal provided by an exemplary embodiment of this specification. Specifically, each ordinary node, upon hearing the cross-chain request event or determining that it has not obtained the cross-chain data within a preset time period after the delegating node issued the cross-chain request, initiates a replacement proposal (checker message) for the delegating node to other ordinary nodes. If any ordinary node receives more than a preset number of replacement proposals from ordinary nodes, it initiates a delegating node replacement transaction in the source blockchain network. For example, if nodeB1 hears the cross-chain request event or determines that it has not obtained the cross-chain data within a preset time period after the delegating node issued the cross-chain request, nodeB1 can initiate a corresponding replacement proposal to other ordinary nodes. This replacement proposal may contain the delegating node's ID, nodeB1's ID, the corresponding cross-chain request ID, etc. This replacement proposal can be initiated in the form of an off-chain message. Thus, if any ordinary node receives more than a preset number of replacement proposals from ordinary nodes, it initiates a delegating node replacement transaction in the source blockchain network, thereby replacing the original delegating node nodeA1 with nodeB1, i.e., nodeB1 replaces nodeA1 and becomes the new delegating node. Of course, the preset duration can be determined according to actual needs, such as 500ms. That is, if the cross-chain data is not obtained within 500ms, a replacement proposal for the delegated node can be initiated to other ordinary nodes.

[0056] Since any ordinary node can initiate a delegated node replacement transaction, the number of such transactions is not limited to one. Therefore, to conserve system resources, blockchain nodes in the source blockchain network can execute the first delegated node replacement transaction that meets the execution conditions and ignore replacement transactions initiated by other ordinary nodes. The execution conditions include: including replacement proposals initiated by more than a preset number of ordinary nodes. In other words, when the number of delegated node replacement transactions is greater than one, blockchain nodes in the source blockchain network can execute only the first delegated node replacement transaction that meets the execution conditions, thereby ignoring replacement transactions initiated by other ordinary nodes, effectively conserving system resources. Specifically, the replacement of delegated nodes can be performed in a pre-set order, such as nodeA1, nodeB1, nodeC1, nodeD1. If the current delegated node is nodeA1, after initiating a delegated node replacement transaction, nodeB1 can replace the malicious nodeA1, making nodeB1 the new delegated node. Of course, this preset order can also be flexibly determined according to actual needs, and this specification does not impose any restrictions on it.

[0057] The preset number can be determined based on the total number of blockchain nodes. In one embodiment, if the total number of blockchain nodes in the source blockchain network is 3f+1, the preset number is f+1, where f is a positive integer. For example, assuming the total number of blockchain nodes is 22, the preset number can be 8. That is, if 8 or more replacement proposals are received, a corresponding delegate node replacement request can be initiated. In other words, the source blockchain network can allow 7 malicious nodes. Therefore, if a replacement proposal is received that exceeds the tolerance (7 malicious nodes), it can be confirmed that the delegate node is abnormal, and a corresponding delegate node replacement transaction can be initiated. Based on the above Byzantine check, even if a delegate node becomes a malicious node, it can be replaced in time to ensure the normal operation of the service.

[0058] In addition to setting up delegated nodes in the source blockchain network, delegated nodes can also be set up in the destination blockchain network. This allows the source blockchain network to avoid receiving cross-chain data returned by every destination node in the destination blockchain network, and instead only need to receive cross-chain data returned by the delegated nodes in the destination blockchain network. Figure 6 As shown, Figure 6This is a schematic diagram illustrating the configuration of a delegated node in a target blockchain network according to an exemplary embodiment of this specification. Specifically, the delegated node can send cross-chain requests to various target nodes in the target blockchain network; or, if the target blockchain network includes delegated nodes, the delegated node in the source blockchain network can send cross-chain requests to delegated nodes in the target blockchain network. Of course, the delegated node in the source blockchain network needs to determine the relevant information of the delegated nodes in the target blockchain network before sending the corresponding cross-chain request. Therefore, in one embodiment, a subnet management contract can be deployed on the blockchain mainnet. This subnet management contract maintains delegated node information in various blockchain subnets built based on the blockchain mainnet. In this case, the delegated node in the source blockchain network can use the delegated node information maintained by the subnet management contract to determine the delegated node in the target blockchain network. Thus, the delegated node in the source blockchain network can send cross-chain requests to the determined delegated node in the target blockchain network, thereby further reducing the amount of data transmission between the source and target blockchain networks. Specifically, when the mainnet node in the blockchain mainnet and the subnet nodes (e.g., source or destination nodes) in the subnets managed by the blockchain mainnet are deployed on the same node device, the mainnet node and the subnet nodes on that node device can share some blockchain plugins running on that node device. In this case, any blockchain node can query the delegated node information of any subnet node's blockchain network through the blockchain plugin. For example, it can read the delegated node information of any blockchain subnet maintained by the blockchain mainnet through a blockchain plugin shared with the mainnet node deployed on its own node device. The aforementioned blockchain plugin can be a plugin deployed in the blockchain mainnet used to call the subnet management contract. Any blockchain node can query the delegated node information of any blockchain subnet by initiating a transaction in subnet0 from the corresponding mainnet node to call the subnet management contract (e.g., reading the subnet state maintained by the subnet management contract). Of course, to ensure query speed, the above transaction can be a consensus-free transaction.

[0059] It should be noted that, due to the asynchronous block consensus processes of the various destination nodes in the target blockchain, the cross-chain data received by the delegating node may be inconsistent. To solve this problem, this specification also proposes timestamp anchoring. Specifically, the delegating node can encapsulate the corresponding first moment in the cross-chain request, so that each destination node in the target blockchain network can use the first moment timestamp encapsulated in the cross-chain request as a benchmark to determine the cross-chain data requested by the source blockchain network, ultimately ensuring that the cross-chain data received by the delegating node is consistent.

[0060] As can be seen from the above embodiments, this specification divides the source blockchain network into delegate nodes and ordinary nodes, so that all subsequent cross-chain requests are executed and sent by the delegate node; and the delegate node receives the cross-chain data returned by the destination blockchain network. This avoids each ordinary node sending cross-chain requests to the destination blockchain network and each ordinary node receiving the returned cross-chain data, effectively reducing the amount of data transmission between the source blockchain network and the destination blockchain network, and reducing the workload of ordinary nodes.

[0061] Corresponding to the embodiments of the foregoing methods, this specification also provides embodiments of apparatus, electronic devices, and storage media.

[0062] Figure 7 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Please refer to... Figure 7 At the hardware level, the device includes a processor 701, a network interface 702, memory 703, non-volatile memory 704, and an internal bus 705, and may also include other hardware required for business operations. One or more embodiments of this specification can be implemented in software, such as the processor 701 reading the corresponding computer program from the non-volatile memory 704 into memory 703 and then running it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0063] Figure 8 This is a block diagram of a cross-chain interaction device provided in an exemplary embodiment. Please refer to... Figure 8 The device is used for cross-chain interaction between a source blockchain network and a destination blockchain network, wherein the source blockchain network includes ordinary nodes and at least one delegate node, and the device includes: The generation unit 802 is used for all blockchain nodes in the source blockchain network to execute cross-chain transactions to generate corresponding cross-chain request events. The cross-chain request sending unit 804 is configured to, when any node in the source blockchain network determines itself to be a delegating node, send a corresponding cross-chain request to the destination blockchain network according to the cross-chain request event, so that the destination blockchain network returns the cross-chain data indicated by the cross-chain request; and, upon receiving the cross-chain data, initiate a corresponding callback transaction in the source blockchain network, so that each ordinary node in the source blockchain network can obtain the cross-chain data.

[0064] Optionally, the cross-chain request sending unit 804 is specifically used for: any node in the source blockchain network, when determining itself to be a delegating node, to perform a self-check on the transaction receipts generated by each block in ascending order of block height; whenever a cross-chain request event is detected, to send the corresponding cross-chain request to the destination blockchain network based on the detected cross-chain request event.

[0065] Optionally, the delegated node maintains a self-checking progress; the device further includes: The self-check progress unit 806 is used by the delegated node to update the self-check progress to the block height of the block or the next block of the block after the self-check of the transaction receipt generated for any block, and the self-check result shows that there is no cross-chain request event or the cross-chain request event detected by the self-check has been processed.

[0066] Optionally, the device further includes: The delegated node replacement unit 808 is used to initiate a replacement proposal for the delegated node to other ordinary nodes when each ordinary node fails to obtain the cross-chain data within a preset time period after listening to the cross-chain request event or determining that the delegated node has issued the cross-chain request; and when any ordinary node receives more than a preset number of replacement proposals from ordinary nodes, it initiates a delegated node replacement transaction in the source blockchain network.

[0067] Optionally, the blockchain node in the source blockchain network executes the first delegated node replacement transaction that meets the execution conditions, and ignores replacement transactions initiated by other ordinary nodes; wherein, the execution conditions include: including replacement proposals initiated by more than a preset number of ordinary nodes.

[0068] Optionally, when the total number of blockchain nodes in the source blockchain network is 3f+1, the preset number is f+1, where f is a positive integer.

[0069] Optionally, the cross-chain request sending unit 804 is specifically used for: the delegating node sending a cross-chain request to each destination node in the destination blockchain network; or, if the destination blockchain network includes a delegating node, the delegating node in the source blockchain network sending a cross-chain request to the delegating node in the destination blockchain network.

[0070] Optionally, the source blockchain network and the destination blockchain network are blockchain subnets managed by the blockchain mainnet. A subnet management contract is deployed on the blockchain mainnet, and the subnet management contract maintains the delegate node information in each blockchain subnet built based on the blockchain mainnet. The cross-chain request sending unit 804 is specifically used for: the delegated node in the source blockchain network reading the delegated node information in each blockchain subnet established based on the blockchain mainnet and maintained by the subnet management contract to determine the delegated node in the destination blockchain network; and the delegated node in the source blockchain network sending a cross-chain request to the determined delegated node in the destination blockchain network.

[0071] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the solution in this specification according to actual needs. Those skilled in the art can understand and implement this without creative effort.

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

[0073] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0074] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

[0076] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

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

[0078] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0079] The above description is merely a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of protection of this specification.

Claims

1. A cross-chain interaction method for performing cross-chain interaction between a source blockchain network and a destination blockchain network, wherein the source blockchain network includes ordinary nodes and at least one delegate node, and the delegate node maintains a self-checking progress; the method includes: All blockchain nodes in the source blockchain network execute cross-chain transactions to generate corresponding cross-chain request events; When any node in the source blockchain network determines that it is a delegating node, it sends a corresponding cross-chain request to the destination blockchain network according to the cross-chain request event, so that the destination blockchain network returns the cross-chain data indicated by the cross-chain request; and, upon receiving the cross-chain data, it initiates a corresponding callback transaction in the source blockchain network, so that each ordinary node in the source blockchain network can obtain the cross-chain data. Sending the corresponding cross-chain request to the target blockchain network based on the cross-chain request event includes: When any node in the source blockchain network determines that it is a delegating node, it performs a self-check on the transaction receipts generated by each block in ascending order of block height to determine whether there is a cross-chain request event in the corresponding transaction receipt of each block; whenever a cross-chain request event is detected, it sends the corresponding cross-chain request to the destination blockchain network based on the detected cross-chain request event. When the delegated node completes a self-check of the transaction receipts generated for any block, and the self-check result shows that there are no cross-chain request events or the cross-chain request events detected by the self-check have been processed, the self-check progress is updated to the block height of the block or the next block of the block.

2. The method according to claim 1, further comprising: If each ordinary node fails to obtain the cross-chain data within a preset time period after listening to the cross-chain request event or determining that the delegate node has issued the cross-chain request, it shall initiate a replacement proposal for the delegate node to other ordinary nodes. If any ordinary node receives a replacement proposal from more than a preset number of ordinary nodes, it may initiate a delegated node replacement transaction in the source blockchain network.

3. The method according to claim 2, wherein the blockchain node in the source blockchain network executes the first delegated node replacement transaction that meets the execution conditions, and ignores replacement transactions initiated by other ordinary nodes; in, The execution conditions include: replacement proposals initiated by more than a preset number of ordinary nodes.

4. According to the method of claim 2 or 3, when the total number of blockchain nodes in the source blockchain network is 3f+1, the preset number is f+1, where f is a positive integer.

5. The method according to claim 1, wherein sending the corresponding cross-chain request to the target blockchain network includes: The delegated node sends cross-chain requests to each destination node in the target blockchain network; or, In cases where the destination blockchain network includes a delegate node, the delegate node in the source blockchain network sends a cross-chain request to the delegate node in the destination blockchain network.

6. The method according to claim 5, wherein the source blockchain network and the destination blockchain network are blockchain subnets managed by the blockchain mainnet, a subnet management contract is deployed on the blockchain mainnet, and the subnet management contract maintains delegated node information in each blockchain subnet built based on the blockchain mainnet; wherein, when the destination blockchain network includes delegated nodes, the delegated node in the source blockchain network sends a cross-chain request to the delegated node in the destination blockchain network, comprising: The delegated nodes in the source blockchain network read the delegated node information in each blockchain subnet built based on the blockchain mainnet, which is maintained by the subnet management contract, to determine the delegated nodes in the destination blockchain network. The delegate node in the source blockchain network sends a cross-chain request to the designated delegate node in the destination blockchain network.

7. A cross-chain interaction device for performing cross-chain interaction between a source blockchain network and a destination blockchain network, wherein the source blockchain network includes ordinary nodes and at least one delegate node, and the delegate node maintains a self-checking progress; the device comprises: A generation unit is used for all blockchain nodes in the source blockchain network to execute cross-chain transactions to generate corresponding cross-chain request events. A cross-chain request sending unit is configured to, when any node in the source blockchain network determines itself to be a delegating node, send a corresponding cross-chain request to the destination blockchain network according to the cross-chain request event, so that the destination blockchain network returns the cross-chain data indicated by the cross-chain request; and, upon receiving the cross-chain data, initiate a corresponding callback transaction in the source blockchain network so that each ordinary node in the source blockchain network can obtain the cross-chain data. The cross-chain request sending unit is specifically used for: any node in the source blockchain network, when determining itself to be a delegating node, to perform a self-check on the transaction receipts generated by each block in ascending order of block height, in order to determine whether there is a cross-chain request event in the corresponding transaction receipt of each block; Whenever a cross-chain request event is detected, a corresponding cross-chain request is sent to the target blockchain network based on the detected cross-chain request event; The device further includes: The self-check progress unit is used by the delegated node to update the self-check progress to the block height of the block or the next block of the block after the self-check of the transaction receipt generated for any block, provided that the self-check result shows that there is no cross-chain request event or the cross-chain request event detected by the self-check has been processed.

8. A computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the steps of the method as claimed in any one of claims 1 to 6.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method as claimed in any one of claims 1 to 6.

Images