A cross-subnet interaction method and device, and a blockchain system

Abstract

This specification provides a cross-subnet interaction method and apparatus, and a blockchain system. The method is applied to a blockchain system consisting of a main blockchain network and multiple blockchain subnets it manages, where each subnet node corresponds to a main network node deployed in its corresponding node device. The method includes: for n message contents to be transmitted from a source subnet node in a source blockchain subnet to a corresponding target subnet node, a first node device determines n forwarding paths corresponding to the n message contents, wherein the target blockchain subnet where any target subnet node is located is distinct from the source blockchain subnet, and n ≥ 2; if the first node device determines that it has the same next-hop node device on the n forwarding paths, it forwards the next-level aggregated message constructed based on the n message contents to that next-hop node device.

Description

Technical Field

[0001] The embodiments in this specification belong to the field of blockchain technology, and particularly relate to a cross-subnet interaction method and apparatus, and a blockchain system. Background Technology

[0002] Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and cryptographic algorithms. In a blockchain system, data blocks are sequentially linked to form a chain-like data structure, and a distributed ledger is cryptographically guaranteed to be immutable and unforgeable. Due to its decentralized, immutable, and autonomous characteristics, blockchain has received increasing attention and application. For example, multiple blockchain nodes corresponding to different users can perform secure multi-party computation (SMPC) on the private data of a particular node based on privacy technologies such as homomorphic encryption and zero-knowledge proofs.

[0003] In some blockchain networks, certain nodes sometimes need to conduct small-scale transactions to prevent other nodes from obtaining these transactions and related data. Therefore, blockchain subnets can be further established on top of the main blockchain network. Since different blockchain subnets are isolated from each other and there are no direct network links connecting them, but there is a need for information sharing and data interaction between them, a cross-chain message interaction scheme implemented through the main blockchain network has been proposed to enable efficient data interaction between these isolated subnets.

[0004] In related technologies, when any source subnet node in a source blockchain subnet sends a cross-chain message to a target subnet node in a target blockchain subnet, it typically needs to construct a cross-chain message and use the network connection established between mainnet nodes in the blockchain mainnet to transmit the cross-chain message to the corresponding target subnet node. Summary of the Invention

[0005] The purpose of this invention is to provide a cross-subnet interaction method and apparatus, and a blockchain system.

[0006] According to a first aspect of one or more embodiments of this specification, a cross-subnet interaction method is proposed, applied to a blockchain system consisting of a blockchain mainnet and multiple blockchain subnets managed by it, wherein subnet nodes in the blockchain subnets correspond to the mainnet nodes deployed in their respective node devices; the method includes:

[0007] For n message contents to be transmitted from a source subnet node in a source blockchain subnet to a corresponding target subnet node, the first node device determines n forwarding paths corresponding to the n message contents, wherein the target blockchain subnet where any target subnet node is located is different from the source blockchain subnet, and n≥2;

[0008] If a first node device determines that it has the same next-hop node device on the n forwarding paths, it will forward the next-level aggregated message constructed based on the n message contents to that next-hop node device.

[0009] According to a second aspect of one or more embodiments of this specification, a blockchain system is proposed, the blockchain system comprising a blockchain mainnet and multiple blockchain subnets managed by it, wherein subnet nodes in the blockchain subnets correspond to the mainnet nodes deployed in their respective node devices; wherein, the first node device where any mainnet node is located is used for:

[0010] For n message contents to be transmitted from a source subnet node to a corresponding target subnet node, determine n forwarding paths corresponding to the n message contents, wherein the target blockchain subnet where any target subnet node is located is different from the source blockchain subnet, and n≥2;

[0011] If it is determined that the first node device has the same next-hop node device on the n forwarding paths, then the next-level aggregated message constructed based on the n message contents will be forwarded to that next-hop node device.

[0012] According to a third aspect of one or more embodiments of this specification, a cross-subnet interaction device is proposed, applied to a blockchain system consisting of a blockchain mainnet and multiple blockchain subnets managed by it, wherein subnet nodes in the blockchain subnets correspond to the mainnet nodes deployed in their respective node devices; the device includes:

[0013] The path determination unit is used to determine n forwarding paths corresponding to n message contents to be transmitted from the source subnet node to the corresponding target subnet node by the first node device, wherein the target blockchain subnet where any target subnet node is located is different from the source blockchain subnet, and n≥2;

[0014] The aggregation forwarding unit is used to forward the next-level aggregated message constructed based on the n message contents to the next-hop node device if the first node device determines that it has the same next-hop node device on the n forwarding paths.

[0015] According to a fourth aspect of one or more embodiments of this specification, an electronic device is provided, comprising:

[0016] processor;

[0017] Memory used to store processor-executable instructions;

[0018] The processor implements the method as described in any one of the first aspects by executing the executable instructions.

[0019] According to a fifth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in any of the first aspects.

[0020] In the above embodiments, for n (n≥2) message contents to be transmitted from a source subnet node in the source blockchain subnet to a corresponding target subnet node, the first node device can be any node device traversed by the forwarding path of these message contents. This node device can determine the n forwarding paths corresponding one-to-one with the n message contents. Furthermore, if it is determined that it (i.e., the first node device) has the same next-hop node device on the n forwarding paths, the next-level aggregated message constructed based on the n message contents will be forwarded to that next-hop node device.

[0021] It is understandable that any message content will be forwarded sequentially by each node device on its corresponding forwarding path until the last node device. For the n forwarding paths corresponding to the n message contents, the first node device has the same next-hop node device on all n forwarding paths, indicating that the first node device needs to transmit all n message contents to that next-hop node device. In this case, by constructing a next-level aggregated message based on the n message contents, and having the first node device forward this aggregated message to the next-hop node device, the aggregated transmission of these n message contents is achieved. In other words, the first node device only needs to forward one message (i.e., the aggregated message) to transmit all n message contents to the next-hop node device at once. Compared to related technologies that require forwarding n cross-chain messages containing corresponding message contents separately, this significantly reduces the number of messages the first node device needs to forward. As can be seen, in scenarios where source subnet nodes in the source blockchain subnet send cross-chain messages to target subnet nodes in the target blockchain subnet through network connections between node devices, this solution can aggregate multiple cross-chain messages according to the forwarding path to reduce the actual number of messages that need to be forwarded between node devices. This helps to avoid network congestion or even failures caused by an excessive number of messages, thereby improving the forwarding efficiency of cross-chain messages and enhancing the stability of the blockchain system. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram illustrating the construction of a blockchain subnet based on a blockchain mainnet, provided as an exemplary embodiment.

[0024] Figure 2 This is an exemplary embodiment of an application scenario diagram for cross-chain interaction.

[0025] Figure 3 This is an exemplary embodiment of an application scenario diagram for cross-subnet interaction.

[0026] Figure 4 This is a flowchart of a cross-subnet interaction method provided in an exemplary embodiment.

[0027] Figure 5 This is a schematic diagram of a cross-subnet interaction process provided in an exemplary embodiment.

[0028] Figure 6 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0029] Figure 7 This is a block diagram of a cross-subnet interaction device provided in an exemplary embodiment. Detailed Implementation

[0030] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] by Figure 1For example, the blockchain mainnet is called `mainnet`, and the mainnet 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 an administrator and only administrators are allowed to initiate transactions to establish a blockchain subnet, then `nodeA` can initiate such a transaction to the mainnet. If `nodeE` is an administrator and only administrators are allowed to initiate such transactions, then `nodeA` through `nodeD` need to request `nodeE` to initiate such a transaction to the mainnet. If `nodeE` is an administrator but allows ordinary users to initiate such transactions, then `nodeA` through `nodeE` can all initiate such a transaction to the mainnet. Of course, whether it is an administrator or an ordinary user, the blockchain node that initiates the transaction to build the 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 the mainnet, and it is not necessarily nodeA to nodeD that initiate the transaction to build the blockchain subnet.

[0035] 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 subnet1 on the mainnet shown, the mainnet can be considered to be at layer one and subnet1 at layer two. In one scenario, the blockchain mainnet in this specification can be an underlying blockchain network, meaning the blockchain mainnet is not a blockchain subnet built on top of other blockchain networks, for example... Figure 1 The "mainnet" in this context can be considered a blockchain mainnet belonging to the underlying blockchain network type. Alternatively, the blockchain mainnet in this specification can also be a subnet of other blockchain networks, such as... Figure 1 If another blockchain subnet is further built upon subnet1, then subnet1 can be considered the corresponding blockchain mainnet. This does not affect the fact that subnet1 also belongs to a blockchain subnet created on the mainnet. Therefore, the blockchain mainnet and blockchain subnet are relative concepts; the same blockchain network can be the blockchain mainnet in some cases and a blockchain subnet in others.

[0036] After the aforementioned 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, and this specification does not impose any limitations on it.

[0037] 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.

[0038] 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.

[0039] 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 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, 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 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).

[0040] It is evident that the first mainnet node and the first subnet node are logically distinct blockchain nodes. From the perspective of the node deployment party, this means that the node devices deployed with 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 can use the exact same public key, they should still be considered different blockchain nodes. For example, in... Figure 1 In this diagram, nodeA in the mainnet is equivalent to the first mainnet node, and the node device deploying nodeA generates nodeA1 belonging to subnet1. This nodeA1 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. The node devices described in this specification can be independent physical devices, or they can be virtual machines or cloud devices provided by cloud services, etc.

[0041] 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 service can be implemented on the main blockchain and another type of service can be implemented on the blockchain subnet, thus ensuring that the service data generated by these two types of services are isolated from each other.

[0042] 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.

[0043] 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.

[0044] 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:

[0045] From: Administrator

[0046] To: Subnet

[0047] method: AddSubnet(string)

[0048] string:genesis

[0049] 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.

[0050] Taking the transaction executed by nodes A through E on the mainnet, calling the AddSubnet() method in the Subnet contract as an example, after the transaction passes consensus, nodes A through E each execute the AddSubnet() method, passing in the configuration information, and obtain the corresponding execution results.

[0051] 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 system 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:

[0052] Event:

[0053] [topic][data]

[0054] [topic][data] ......

[0056] 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.

[0057] 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.

[0058] As can be seen, the execution result of the aforementioned Subnet contract can include the configuration information. This execution 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:

[0059] Event:

[0060] [topic:other][data]

[0061] [topic:subnet][data] ......

[0063] Therefore, when nodes A through E detect the first event, since the 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 the 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:

[0064] {subnet1;

[0065] The public key of nodeA, the IP address of nodeA, the port number of nodeA, etc.;

[0066] The public key of nodeB, the IP address of nodeB, the port number of nodeB, etc.;

[0067] The public key of nodeC, the IP address of nodeC, the port number of nodeC, etc.;

[0068] The public key of nodeD, the IP address of nodeD, the port number of nodeD, etc.;

[0069] }

[0070] 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 does not exist, it means subnet1 is the new blockchain subnet to be created; if it exists, it means subnet1 already exists.

[0071] 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.

[0072] Besides the network identifier subnet1, the aforementioned data field also includes the 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 event and the content of the network event indicates that the first mainnet node belongs to the node member, the node device deploying the first mainnet node can obtain the configuration information or genesis block contained in the network event. Alternatively, the first blockchain node can listen to the generated receipts, and if it detects the network event and the content of the network event indicates that the first blockchain node belongs to the node member, it can trigger the node device deploying the first blockchain node to obtain the configuration information or genesis block contained in the network event.

[0073] As mentioned earlier, node devices can directly monitor receipts. Assuming nodes A through E are deployed on nodes 1 through 5 respectively, and nodes 1 through 5 can monitor receipts generated by nodes A through E, then if they detect that subnet 1 is a newly formed blockchain subnet, nodes 1 through 5 will further identify the identity information of the node members contained in the data field to determine their processing method. Taking node A and node 1 as an example: if node 1 finds that the data field contains node A's public key, IP address, and port number, then node 1, based on the aforementioned message mechanism, obtains the configuration information from the data field, generates a genesis block containing this configuration information, and deploys node A1 locally. Node A1 then loads the generated genesis block, thus becoming a subnet node of subnet 1. Similarly, node 2 can generate node B1, node 3 can generate node C1, and node 4 can generate node D1. Furthermore, if node device 5 finds that the identity information contained in the data field does not match its own, then node device 5 will not generate the genesis block based on the configuration information in the data field, nor will it generate a blockchain node in subnet1.

[0074] As mentioned earlier, blockchain nodes in the mainnet can listen to receipts and trigger relevant processing based on the listening results. For example, when nodes A through E 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 instance, nodes A through D will find their own identity information, such as public key, IP address, and port number, in the data field. Assuming nodes A through D are deployed on node devices 1 through 4 respectively, taking node A and node device 1 as an example: node A will trigger node device 1, causing node device 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 device 1 will also deploy node A1 locally, which loads the generated genesis block and thus becomes a subnet node in subnet1. Similarly, node B will trigger node device 2 to generate node B1, node C will trigger node device 3 to generate node C1, and node D will trigger node device 4 to generate node D1. Furthermore, nodeE will find that the identity information contained in the data field does not match its own. Assuming that nodeE is deployed on node device 5, then node device 5 will not generate the genesis block based on the configuration information in the data field, nor will it generate nodes in subnet1.

[0075] 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 nodeA1's identity information in the data field, it can generate a genesis block, deploy nodeA1, and have nodeA1 load the genesis block; or, if nodeA finds nodeA1's identity information 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 methods for other blockchain nodes or node devices are similar, and will not be elaborated here.

[0076] 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.

[0077] 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 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 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 subnet, it can create a second instance within the process. This second instance is distinct from the first instance and forms the second blockchain node in the subnet. When the first instance and the second instance reside in the same process, since cross-process interaction is not involved, the deployment difficulty of the first subnet node can be reduced and the deployment efficiency improved. Of course, the second instance may also reside in different processes on the node device than the first instance, and this specification does not impose any restrictions on this. For example, the node device can create the first instance in the first process to form the first blockchain node in the blockchain mainnet. When the node member corresponding to the node device wants to participate in the formation of the blockchain subnet, it can start a second process that is different from the first process and create a second instance in the second process. This second instance is different from the first instance mentioned above, 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., database) on that node device, and the storage used by each blockchain node deployed on any node device is isolated from each other.

[0078] Using the methods described above, blockchain subnets can be created on the mainnet of the blockchain. Figure 1For example, the mainnet originally contains nodes A through E. Subnet 1 can be built on top of the mainnet, 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, subnet 2 or more blockchain subnets can be built on the mainnet, where subnet 2 contains nodes A2, B2, C2, and E2, with nodes A and A1, A2, B and B1, B2, C, C1, C2, D and D1, and E and E2 deployed on the same node device. Furthermore, subnet 1 and subnet 2 can be used as new blockchain mainnets, and further blockchain subnets can be built on top of them, the process being similar to the construction of subnet 1 or subnet 2, and will not be elaborated here. As can be seen, the above-mentioned method of initiating transactions on the blockchain mainnet to select node members to create a blockchain subnet ensures that the subnet nodes of the newly created blockchain subnet are all deployed on the node devices where the mainnet nodes of the blockchain mainnet are located. In other words, from the perspective of the node devices, the node devices where the subnet nodes of the blockchain subnet are located are a subset of the node devices where the mainnet nodes are located. In other words, the node devices where the subnet nodes of the blockchain subnet are deployed also have the mainnet nodes of the blockchain mainnet deployed on them.

[0079] Besides selecting node members through transactions on the mainnet to create a subnet, other methods can be used to create subnets and subject them to the management of the mainnet. For example, a subnet can be created on the mainnet through registration (hereinafter referred to as registration networking). This allows an existing blockchain network to be directly registered with the mainnet, making the newly registered network a subnet of the mainnet. Through registration-based networking, the subnet information of the blockchain subnet to be built is directly registered to the main blockchain network. This allows the main blockchain network to acquire relevant information about the subnet (by receiving and executing transactions sent by the subnet to be built, which associate its identity information with the subnet identifier assigned to that subnet). This includes the subnet identifier and operational status, the public keys and plugin configuration information of each node member, and the IP addresses and port information of each node device. This information is written into the contract status of the corresponding system contract on the main blockchain network. Thus, the main blockchain network gains management rights over the subnet. After registration, the subnet is considered complete. Since registration-based networking does not require specifying node members on the main blockchain network through transactions, the subnet nodes in a subnet built through this method can be completely or partially different from the node devices deployed on the main blockchain network. For example… Figure 1 In the mainnet, a subnet4 was created using a registration-based networking method. Figure 1 (Not shown in the image) Assuming that the mainnet itself contains mainnet nodes nodeA to nodeE, which are deployed on node devices 1 to 5 respectively, then the subnet nodes corresponding to subnet4 can be deployed on any other node device other than node devices 1 to 5. Alternatively, one or more subnet nodes in subnet4 can be deployed on any node device among node devices 1 to 5 (but it is still necessary to ensure that only one subnet node from subnet4 is deployed on a node device), while the other subnet nodes in subnet4 can be deployed on any other node device other than node devices 1 to 5. Of course, the subnet nodes in subnet4 can also all be deployed on node devices 1 to 5.

[0080] First, combine Figure 1 and Figure 2 This specification provides a brief description of the cross-chain interaction (also known as cross-subnet interaction) scheme to explain how cross-chain interaction is achieved between different blockchain subnets through the main blockchain network, even when there is no direct network connection between them. Figure 1As shown, two blockchain subnets, subnet1 and subnet2, are created on top of the mainnet. Figure 2 The diagram shown illustrates an application scenario where subnet1 and subnet2 implement cross-chain interaction based on the mainnet.

[0081] like Figure 2 As shown, node device 3 simultaneously deploys nodeC belonging to the mainnet and nodeC1 belonging to subnet 1. NodeC and nodeC1 are specifically blockchain node instances (hereinafter referred to as blockchain nodes) formed by running pre-deployed blockchain platform code in a locally deployed virtual machine on node device 3. The data related to nodeC during its operation is stored in the database corresponding to nodeC, while the data related to nodeC1 during its operation is stored in the database corresponding to nodeC1. Similarly, node device 5 simultaneously deploys nodeE belonging to the mainnet and nodeE2 belonging to subnet 2. Other node devices also simultaneously deploy multiple blockchain nodes, for example... Figure 2 The node device 1 shown in the example simultaneously deploys three blockchain nodes belonging to different blockchain networks: nodeA, nodeA1, and nodeA2. Further details are omitted here. Additionally, any node device can deploy blockchain consensus code, which the node device can run to create a local consensus component instance. Furthermore, node devices can also deploy P2P component code managed as plugins, which the node device can run to create a local P2P component instance, i.e., a P2P plugin. For example... Figure 2 Both node devices 3 and 5 run P2P plugins locally. These plugins can be shared by different blockchain nodes on the same node device. For example, nodeC and nodeC1 on node device 3 can call the same P2P plugin running on node device 3 to share its functionality and data. The node devices also deploy blockchain service code, which can be run to create service instances locally. Each node device can implement at least one service instance, such as a storage instance for data read / write functionality, a computing instance for privacy computing, or an encryption instance for data encryption, etc., which will not be elaborated further.

[0082] Taking the example of a source node (nodeC1) in the source blockchain network subnet1 sending a cross-chain message to a destination node (nodeE2) in the destination blockchain network subnet2, this manual illustrates the process of cross-chain interaction between any blockchain node in any blockchain subnet and another blockchain node in another blockchain network. In the cross-chain scenario described in the embodiments of this specification, each source node in the source blockchain network and each destination node in the destination blockchain network are equipped with a mainnet node from the blockchain mainnet. In subnet1, nodeC1's node device 3 also has a mainnet node nodeC deployed on it, and in subnet2, nodeE2's node device 5 also has a mainnet node nodeE deployed on it. Although there is no direct network connection between subnet1 and subnet2, a network connection link established beforehand between nodeC on node device 3 and nodeE on node device 5, as implemented during the formation of the mainnet, allows node device 3 and node device 5 to communicate with each other. Specifically, the network connection link established during the formation of the mainnet is the consensus link established between consensus nodes in the mainnet for consensus transactions and / or the synchronization link for synchronizing blocks. Therefore, nodeC1 can send cross-chain messages from node device 3 to node device 5 through the network connection link established between nodeC and nodeE.

[0083] In the embodiments of this specification, the mainnet nodes and subnet nodes on the same node device share the blockchain communication plugin running on that node device, such as the aforementioned P2P plugin. The network connection link implemented when forming the mainnet is specifically established by nodeC and nodeE using the P2P plugins on node devices 3 and 5, respectively. Since the P2P plugin on the node device can be shared by all blockchain nodes on that node device, nodeC1 in subnet1 can establish a network connection with the P2P plugin running on node device 5, which belongs to nodeE2, by calling the P2P plugin running locally on node device 3 and using the network connection between node device 3 and node device 5 based on the P2P plugin implemented when forming the mainnet. This allows cross-chain messages to be sent to node device 5, thereby further realizing network communication with nodeE2. This eliminates the need to establish a new network connection link between the source blockchain network and the destination blockchain network. Instead, the network communication between the source node in the source blockchain network and the destination node in the destination blockchain network is realized through the network connection link pre-established by the underlying blockchain mainnet.

[0084] In implementing service functions, nodes in subnet1 may need to use data stored by nodes in subnet2. Therefore, subnet1 can request this data from subnet2. During the data acquisition process using the cross-chain interaction scheme described in this specification, nodeC1 and nodeC are deployed on node device 3, nodeE2 and nodeE are deployed on node device 5, and the remaining blockchain nodes are deployed on other node devices. For example, subnet1 can send a cross-chain request to subnet2 to obtain the contract status of a specific field in a specific contract stored in subnet2's node database. It can be understood that "subnet1 sending a cross-chain request to subnet2" is equivalent to "a subnet node in subnet1 (i.e., the source node) sending a cross-chain request to a subnet node in subnet2 (i.e., the destination node)."

[0085] Specifically, any node in subnet1 can encapsulate the network identifier of the target blockchain network subnet2 in the cross-chain request. By calling the P2P plugin deployed locally on the node device and shared with the mainnet nodes, the cross-chain request is broadcast through the network connection link of the mainnet to the P2P plugin running on each node device with the 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, which have deployed 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 deployed a blockchain node in the blockchain network corresponding to the network identifier based on 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 3 will also forward it based on the network identifier it carries. However, since node device 3 does not have a blockchain node in subnet2 deployed locally, node device 3 will not retain the cross-chain request, but will further forward the cross-chain request to other node devices with deployed 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, nodeC1 in subnet1 can encapsulate the identity information of nodeE2 in the cross-chain request and call the P2P plugin running locally on node device 3. 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 mainnet, 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.

[0086] The above process describes how the source blockchain network sends cross-chain requests to the destination blockchain network through the network connection links established between the mainnet nodes in the blockchain mainnet. Similarly, the destination blockchain network can also transmit messages to the source blockchain network in a similar way, such as returning the cross-chain data corresponding to the block request sent by the source node to the source blockchain network. In this way, through the bidirectional communication channel formed between the source blockchain network and the destination blockchain network, network communication between the source node in the source blockchain network and the destination node in the destination blockchain network is realized.

[0087] Figure 2 Only a combination Figure 1 This is an illustrative example using blockchain subnets subnet1 and subnet2. In fact, Figure 1 Cross-chain interaction is possible between the various blockchain networks in this specification, and this specification does not impose any restrictions on the relationships between blockchain networks engaging in cross-chain interaction. For example, cross-chain interaction can be achieved between the blockchain mainnet and blockchain subnet1, and between the blockchain mainnet and blockchain subnet2; the specific process will not be elaborated further.

[0088] The aforementioned cross-chain interaction scheme relies on the network connection links established by the blockchain mainnet, specifically through the network links established between various mainnet nodes. Building upon this, considering that the blockchain mainnet typically includes not only consensus nodes (participating in transaction consensus) but also non-consensus nodes (participating only in block synchronization), a cross-subnet interaction scheme based on forwarding routing is proposed to enable subnet nodes within the node devices of non-consensus nodes to also achieve cross-subnet interaction based on the consensus links established by the blockchain mainnet. Specifically, the node device where the source subnet node resides determines the forwarding path of the cross-chain message to be sent by the source subnet node according to the network topology between the node devices of various mainnet nodes in the blockchain mainnet. The node devices along this path then cooperate to forward the cross-chain message within the blockchain mainnet, ultimately delivering it to the target subnet node.

[0089] Figure 3 This is an exemplary embodiment illustrating an application scenario for cross-subnet interaction. For example... Figure 3 As shown, this scene is Figure 1Based on the scenario shown, assume that only some mainnet nodes (nodeA, nodeB, and nodeD) are consensus nodes on the blockchain mainnet. For consensus nodes, there are pairwise connected consensus links between them. However, for non-consensus nodes (nodeC or nodeE) on the mainnet, since they do not need to participate in the consensus process, they only need to establish a synchronization link with any one of the consensus nodes for synchronizing blocks. For example, nodeC has a synchronization link with nodeA, and nodeE has a synchronization link with nodeB. However, nodeC does not have a direct network link to nodeB, nodeD, and nodeE. Similarly, nodeE does not have a direct network link to nodeA, nodeC, and nodeD. At this point, assuming that nodeC1, which belongs to subnet1 and is simultaneously deployed on equipment3, where nodeC is located, wants to send a cross-chain message to nodeE2, which belongs to subnet2 and is simultaneously deployed on equipment5, where nodeE is located, then nodeC1 can determine the forwarding path from equipment3 to equipment5 according to the network topology between the various node devices, such as equipment3→equipment1→equipment2→equipment5 (or equipment3→equipment1→equipment4→equipment2→equipment5). Then, starting from equipment3, the various node devices on this path cooperate with each other to forward the cross-chain message step by step to equipment5, and finally send it to nodeE2, thereby realizing cross-chain interaction between subnet nodes corresponding to non-consensus nodes.

[0090] Any node in a blockchain subnet may need to send multiple cross-chain messages, meaning it needs to send multiple message contents to subnet nodes in other blockchain subnets. To address this, the first node device in related technologies needs to construct corresponding cross-chain messages for each message content and forward them to the corresponding target subnet node's node device according to the forwarding path of each cross-chain message. Understandably, any message content sent by the same subnet node needs to be transmitted through a single cross-chain message. Therefore, when any subnet node needs to send multiple message contents, multiple cross-chain messages need to be transmitted within the blockchain mainnet, requiring multiple forwarding paths to be determined among node devices to forward the corresponding cross-chain messages. Using this method, the burden on node devices for processing cross-chain messages is heavy, potentially leading to network congestion or even failures due to the excessive number of messages. The forwarding efficiency of cross-chain messages and the stability of the blockchain system are both relatively low.

[0091] To address this issue, this specification proposes a cross-subnet interaction scheme. When the forwarding paths corresponding to multiple cross-chain messages overlap (i.e., at least some links on each forwarding path are identical), the multiple cross-chain messages are merged into a single aggregated message, thereby effectively reducing the number of messages that node devices need to forward. The following section provides a detailed description of this cross-subnet interaction scheme in conjunction with the accompanying drawings.

[0092] Figure 4 This is a flowchart illustrating a cross-subnet interaction method as provided in an exemplary embodiment. The method is applied to a blockchain system consisting of a mainnet and multiple subnets managed by it, wherein subnet nodes in a subnet correspond to the mainnet nodes deployed in their respective node devices; the method includes:

[0093] Step 402: For n message contents to be transmitted from the source subnet node in the source blockchain subnet to the corresponding target subnet node, the first node device determines n forwarding paths corresponding to the n message contents, wherein the target blockchain subnet where any target subnet node is located is different from the source blockchain subnet, and n≥2.

[0094] In the embodiments described in this specification, the source blockchain subnet can be any blockchain subnet within the blockchain system, which is created based on and managed by the main blockchain network. For example, the source blockchain subnet can be... Figure 1 The subnet1 or subnet2 shown, or it could also be Figure 3 The subnet is shown as either subnet1 or subnet2. Furthermore, the source subnet node can be any node in the source blockchain subnet. For example, if the source blockchain subnet is subnet1, the source subnet node can be any node from nodeA1 to nodeD1, such as nodeC1, etc. Each subnet node described in this specification is located in a node device that also deploys a mainnet node. The subnet node corresponds to the mainnet node. For example, nodeC1 in subnet1 corresponds to nodeC in the mainnet. The subnet node nodeC1 and the mainnet node nodeC are deployed in the same node device, equipment3.

[0095] Furthermore, the target blockchain subnet where any target subnet node is located is distinct from the source blockchain subnet; that is, the target blockchain subnet and the source blockchain subnet are not the same subnet. In other words, the n message contents need to be transmitted to a target blockchain subnet that is distinct from the source blockchain subnet. Here, any message content described in this specification can be data received by the source subnet node or data maintained by the node itself (such as original data participating in multi-party computation, locally maintained on-chain data, etc.), or it can be instruction information generated by the source subnet node to instruct the target subnet node to perform a preset operation (such as a self-generated signature, etc., proof information). Additionally, any two message contents among the n message contents can be the same or different; any two message contents can correspond to the same target subnet node or correspond to different target subnet nodes. If any two message contents correspond to different target subnet nodes, these two target subnet nodes can belong to the same target blockchain subnet or belong to different target blockchain subnets. Figure 3 As shown, if the source subnet node is nodeC1, then the target subnet nodes corresponding to any two message contents in the n message contents can both be nodeC2, or they can be nodeC2 and nodeB2 respectively. If the mainnet also manages subnet3, these two target subnet nodes can also be any subnet node in nodeC2 and subnet3 (such as nodeE3, etc.), which will not be elaborated further.

[0096] In the implementation of this specification, any message content corresponds to a forwarding path, which consists of multiple node devices. The starting point is the node device where the source subnet node is located, and the ending point can be the node device where the target subnet node is located, or it can be the node device where any other subnet node in the target blockchain subnet belongs. For example, if... Figure 3 As shown, nodeC1 needs to transmit message content 1 and message content 2 to nodeB2 and nodeE2 respectively. The forwarding path corresponding to message content 1 can be equipment3→equipment2, in which case equipment can send the received message content to nodeC2. The forwarding path corresponding to message content 2 can be equipment3→equipment5, in which case equipment5 can send the received message content to nodeE2, or it can be equipment3→equipment2, in which case equipment2 can send the received message content to nodeC2, and then nodeC2 forwards it to nodeE2 through the internal network of subnet2.

[0097] Furthermore, the first node device simultaneously belongs to all n forwarding paths, meaning all n forwarding paths pass through the first node device. In one embodiment, the first node device can be the source node device where the source subnet node resides. In this scenario, the first node device can first determine the n message contents that need to be transmitted, and then further determine the n forwarding paths corresponding to each of the n message contents, that is, determine the corresponding forwarding path for each message content. Obviously, at this time, the first node device is the common starting point of the n forwarding paths.

[0098] In another embodiment, the first node device may not be the source subnet node, meaning the first node is not the starting point of the n forwarding paths, but can be the ending point, or an intermediate node device between the starting and ending points. Of course, the first node device can be the common ending point of the n forwarding paths; or it can be the ending point of some (at least one) of the n forwarding paths, while simultaneously being an intermediate node device for the remaining forwarding paths. When the first node device is not the source subnet node, it can receive aggregated messages forwarded by its previous-hop node device in the n forwarding paths. This aggregated message will be referred to below as the first node device's previous-level aggregated message. It is understood that the first node device corresponds to the same previous-hop node device on the n forwarding paths. The n message contents are recorded in the message body of the previous-level aggregated message received by the first node device. Based on this, the first node device can, upon receiving the previous-level aggregated message, use the n message contents contained in the message body as the n message contents it needs to transmit.

[0099] The header of the higher-level aggregated message may also record path information for the n message contents. This allows the first node device to determine n forwarding paths corresponding to the n message contents, which can be generated by the source subnet node based on its own determined forwarding paths. The source subnet node can first determine the corresponding n forwarding paths for the n message contents to be transmitted, then generate the path information for these n forwarding paths and record it in the header of its own generated primary aggregated message (while simultaneously recording the n message contents in the message body). The path information may include the device identifiers of the node devices traversed by each forwarding path; alternatively, if a mainnet node is deployed in any node device, the path information may also include the node identifiers of the mainnet nodes deployed in the node devices traversed by each forwarding path. For example, the device identifier or node identifier may be a name, number, or public key.

[0100] In one embodiment, the source node device where the source subnet node is located can also maintain the network topology between the node devices where each mainnet node in the blockchain mainnet is located. Since each node device maintains a corresponding mainnet node, this network topology can be generated based on the network connection relationships between the mainnet nodes in the blockchain mainnet. Specifically, since the blockchain mainnet typically contains both consensus nodes and non-consensus nodes, the network links corresponding to the network connection relationships between the mainnet nodes can include: consensus links established between consensus mainnet nodes in the blockchain mainnet, and synchronization links established between consensus mainnet nodes and non-consensus mainnet nodes.

[0101] Based on the aforementioned network topology, the source subnet node can determine the forwarding path corresponding to any message content in multiple ways. For example, the source subnet node can first determine any target subnet node corresponding to any message content and any target node device it resides in. Since the blockchain mainnet typically maintains basic information about each blockchain subnet managed by the mainnet (such as which subnet nodes are included, the identity information of each subnet node, and the connection status between each subnet node), and the mainnet node and subnet nodes deployed in any node device can share functional plugins within that node device (such as cache plugins that maintain the aforementioned basic information), the source subnet node can accurately determine which target subnet nodes it needs to send message content to and the target node devices where each target subnet node resides.

[0102] Furthermore, the source subnet node can determine the forwarding path with the fewest total hops between the source node device and any target node device based on the network topology, and use this path as the forwarding path corresponding to any message content. Each hop between the source node device and any target node device is considered a single hop. Alternatively, if the source node device also maintains network latency information corresponding to the network topology, the forwarding path with the fewest total latency between the source node device and any target node device can be determined from the network topology based on this network latency information, and used as the forwarding path corresponding to any message content. When determining the forwarding path based on the network latency information, the network latency information may include the link latency of network links in the network topology, or it may include the node latency of node devices in the network topology when forwarding messages; of course, it may also include both link latency and node latency, which can be determined according to the network structure and actual needs, and this specification does not limit this. For example, when the network delay information only includes link delay, the total delay of any forwarding path can be the sum of the link delays between all adjacent node devices on that forwarding path (hereinafter referred to as total link delay); when the network delay information only includes node delay, the total delay of any forwarding path can be the sum of the node delays of all node devices on that forwarding path (hereinafter referred to as total node delay); and when the network delay information includes both link delay and node delay, the total delay of any forwarding path can be the sum of the node delays of all node devices on that forwarding path and the link delays between all adjacent node devices (i.e., the sum of the total link delay and the total forwarding delay of that forwarding path). Here, the link delay between any two node devices is the time delay required for a message to travel from one node device to the other; the node delay of a node device refers to the time required for a message to travel from entering that node device to being forwarded from that node device, specifically including the sum of the time delays required for the node device to parse the message, look up the routing table, and forward it.

[0103] like Figure 5As shown, assume the blockchain mainnet consists of at least node A through node E, where node A and node E are non-consensus nodes, and node B, node C, and node E are consensus nodes. Node A is deployed in equipment 1, node B in equipment 2, node C in equipment 3, node D in equipment 4, and node E in equipment 5. Additionally, equipment 1, equipment 2, and equipment 3 each deploy subnet nodes of blockchain subnet 1, namely node A1, node B1, and node C1; equipment 1, equipment 3, equipment 4, and equipment 5 each deploy subnet nodes of blockchain subnet 2, namely node A2, node C2, node D2, and node E2; and equipment 2 and equipment 4 each deploy subnet nodes of blockchain subnet 3, namely node B3 and node D3. Of course, for the blockchain mainnet and blockchain subnets subnet1, subnet2 and subnet3 mentioned above, any of these networks may contain other nodes not shown in the diagram, which will not be elaborated further.

[0104] Specifically, the node latency of equipment1 is 2, the node latency of equipment3 is 5, the link latency of the network link between equipment1 and equipment2 is 10, and the link latency of the network link between equipment3 and equipment4 is 50. The node latency of other node devices and the link latency of the network link between other two node devices can be found in [reference needed]. Figure 5 The details will not be elaborated further. In the embodiments of this specification, the numerical values ​​corresponding to link delay and node delay can represent specific latency durations, or they can represent other latency indicators related to specific latency durations. It is only necessary to ensure that the link delay and node delay use a unified unit; this specification does not impose any restrictions on this. For example, the link delay 10 of the network link between equipment1 and equipment2 can be understood as 10 microseconds (µs), meaning that a message needs to travel 10µs through this network link. Similarly, the node delay 5 of equipment3 should be understood as 5µs.

[0105] exist Figure 5In the network topology shown, let's assume that nodeA1 in subnet1 is the source subnet node, which needs to transmit message content data1, data2, data3, and data4 to nodeC2, nodeD2, and nodeE2 in subnet2, and nodeD3 in subnet2, respectively. In this scenario, the source blockchain subnet is subnet1, and the source subnet node is nodeA1. Taking the forwarding path with the minimum total latency as an example, nodeA1 can determine that the forwarding path corresponding to data1 is "L1: equipment1→equipment2→equipment3", the forwarding paths corresponding to data2 and data3 are both "L2 and L3: equipment1→equipment2→equipment3→equipment4", and the forwarding path corresponding to data4 is "L4: equipment1→equipment2→equipment3→equipment4→equipment5". The total delay of any forwarding path can be the sum of the node delays of all nodes included in the path (or excluding the target node) and the link delays between adjacent nodes on the path (i.e., the sum of the aforementioned total link delay and total node delay). Taking data2 as an example, there are two possible forwarding paths from equipment1 to equipment4: "L21: equipment1→equipment2→equipment4" and "L22: equipment1→equipment2→equipment3→equipment4". The total delay of L21 is 2++3+3+10+100=118, and the total delay of L22 is 2+5+3+10+20+50=90. Obviously, the total delay of L22 is the smallest, so L22 is determined as the (shortest) forwarding path L2 for data2.

[0106] As can be seen from the forwarding paths corresponding to the various message contents, there are some overlapping links between L1 to L4. For example, there is an overlap between L1 and L2 ("equipment1→equipment2→equipment3"), L2 and L3 are completely overlapping, and there is an overlap between L2 (and L3) and L4 ("equipment1→equipment2→equipment3→equipment4"). Based on this, the various message contents can be aggregated to convert the messages that need to be forwarded separately into a single aggregated message for forwarding, thereby effectively reducing the number of messages that the node devices need to forward.

[0107] Step 404: If the first node device determines that it has the same next-hop node device on the n forwarding paths, it forwards the next-level aggregated message constructed based on the n message contents to the next-hop node device.

[0108] As mentioned earlier, when the first node device is not the source node device, it can receive the aggregated message sent by the previous-hop node device on its forwarding path. Assuming the message contains S message contents, at least some of these S message contents may need to be forwarded to the next node device—this at least some message contents may have multiple messages with the same next-hop node device, or at least one message content with a different next-hop node device; furthermore, at least some of the S message contents may need to be sent to a target subnet node deployed in the first node device, or other target subnet nodes within the blockchain subnet to which the target subnet node deployed in the first node device belongs, etc. The first node device can process each message content in a corresponding manner to address these various situations. For example, in response to receiving an aggregated message from the previous level, the first node device can first determine whether the endpoint of the forwarding path corresponding to each of the S message contents is the first node device itself: if the endpoint of the forwarding path corresponding to any message content is the first node device (at this time, the first node device does not have a corresponding next-hop node device in the forwarding path), then the message content does not need to be forwarded to other node devices; conversely, if the endpoint of the forwarding path corresponding to any message content is not the first node device (at this time, the first node device has a corresponding next-hop node device in the forwarding path), then the message content still needs to be forwarded to the next-hop node device of the first node device.

[0109] In one embodiment, if it is determined that there are n message contents that need to be forwarded and n = S (i.e., all S message contents need to be forwarded), then the first node device can, in response to having the same next-hop node device on the n forwarding paths, forward the upper-level aggregated message as the lower-level aggregated message to that next-hop node device. Following the aforementioned embodiment where nodeA1 transmits four message contents as the source subnet node, when forwarding paths L1 to L4 corresponding one-to-one with the aforementioned data1 to 4 are determined, nodeA1 can generate an initial aggregated message: the message header of this message contains the path information of forwarding paths L1 to L4, and the message body contains data1 to L4. Therefore, equipment1 can forward the initial aggregation message to equipment2. For equipment2 (which becomes the first node device after receiving the aggregation message), this aggregation message is the previous-level aggregation message it received. Based on the message header and body, we can determine that n = S = 4 (as shown by the "4" inside the elliptical dashed line next to the arrow between equipment1 and equipment2) and the next-hop node device is equipment3. Therefore, equipment2 can forward this previous-level aggregation message as its corresponding next-level aggregation message to equipment3. It is understandable that for equipment3, the aggregation message it receives from equipment2 is its previous-level aggregation message, which will not be elaborated further.

[0110] In another embodiment, if the first node device is not the source node device, then the first node device may be the target node device (i.e., the end point of this part of the forwarding path) in at least part of the forwarding path. In this case, the first node device may have deployed the target subnet node corresponding to this part of the forwarding path or other subnet nodes in the corresponding target blockchain subnet. Alternatively, the first node device may also be an intermediate node device other than the source node device and the target node device in part of the forwarding path. In this case, the target subnet node corresponding to this part of the forwarding path is not deployed in the first node device, but is deployed in other node devices after the first node device on the corresponding forwarding path. It can be seen that in the upper-level aggregated message containing S message contents received by the first node device, there may be at least some target subnet nodes corresponding to the message contents deployed in the first node device, and there may also be at least some target subnet nodes corresponding to the message contents deployed in other node devices after the first node device.

[0111] In response to receiving the aforementioned aggregated message from the previous level, the first node device can determine, from the S message contents, the destination of the corresponding forwarding path as m1 (S≥m1≥0) message contents of the first node device (the target subnet nodes corresponding to these message contents are deployed in the first node device). Furthermore, in response to m1>0, the first node device can send the m1 message contents to the corresponding target subnet nodes deployed locally; alternatively, it can send a portion of the m1 message contents to the corresponding target subnet nodes deployed locally, and send the cross-chain messages of the remaining message contents to a subnet node deployed locally belonging to the target blockchain subnet, so that the subnet node can forward the cross-chain messages to the corresponding target subnet node in its own target blockchain subnet; or, it can send all m1 message contents to a subnet node deployed locally belonging to the target blockchain subnet for forwarding, thereby completing the transmission process of these m1 message contents. For example, after receiving the aggregated message from the parent layer of equipment2, equipment3 can determine from its message header and body that S = 4 (as shown by the "4" inside the elliptical dashed line next to the arrow between equipment2 and equipment3) and m1 = 1 (the message content corresponding to m1 is data1). Therefore, it can send data1 to the locally deployed nodeC2, or it can send the cross-chain message containing data1 to nodeC2, thus completing the transmission process of data1. As another example, if the target subnet node corresponding to data1 is not nodeC1, but nodeF1 in subnet1 (not shown in the diagram), then when S = 4 and m1 = 1, equipment3 can send the cross-chain message containing data1 to nodeC1, and nodeC1 will forward the cross-chain message to nodeF1 through the internal network of subnet1, thus completing the transmission process of data1. Understandably, whether any message content needs to be transmitted to nodeC1 or nodeF1 can be determined by nodeA1 when determining the forwarding path, and the identification information of the corresponding target subnet node is also recorded in the message header, so as to achieve the shortest overall forwarding path between the main network and the subnet.

[0112] Furthermore, in response to receiving the aforementioned aggregated message from the previous level, the first node device can determine m2 (S≥m2≥0) message contents from the S message contents. The next-hop node device on the forwarding path corresponding to any one of these m2 message contents is distinct from the next-hop node device on the forwarding path corresponding to any other message content included in the aggregated message from the previous level. In other words, all m2 message contents need to be forwarded to their respective next-hop node devices, and the next-hop node device corresponding to any one of these message contents is different from the next-hop node devices of the other message contents. Clearly, when m2>0, the first node device can include these m2 message contents separately in cross-chain messages and forward them to their respective next-hop node devices. For example... Figure 5 As shown, after receiving the aggregated message from the previous level of equipment3, equipment4 can determine from its message header and body that: S = 3 (as shown by the "3" inside the elliptical dashed line next to the arrow between equipment3 and equipment4), m1 = 2 (the message content corresponding to m1 is data2 and data3), and m2 = 1 (the message content corresponding to m2 is data4). Therefore, it can (according to the identifier information of the target subnet node recorded in the message header) send data2 and data3 to the locally deployed nodeD2 and nodeD3 respectively, thus completing the transmission process of data2 and data3. In addition, since the next-hop node device of the first node device (i.e., equipment4) on the L4 of data4 (corresponding to m2) is equipment5, equipment4 can construct a cross-chain message containing data4 and forward it to equipment5, thus completing the transmission process of data4.

[0113] Figure 5 Among the node devices shown, equipment1, equipment2, equipment3, and equipment4 can serve as the first node device in different scenarios. It is understood that for any first node device in any scenario, its corresponding n, m1, and m2 satisfy n + m1 + m2 = S.

[0114] In one embodiment, the n message contents that the first node device needs to forward to the same next-hop node device may have various scenarios. For example, the n message contents may be pairwise distinct, or they may be all or partially identical. It is understood that when the n message contents are pairwise distinct, all n message contents can be recorded in the message body of the next-level aggregated message so that the next-hop node device can know each message content. However, if all or partially identical n message contents are still recorded in the message body of the next-level aggregated message, the message body data volume may become too large, even exceeding the maximum data volume that can be transmitted in a single transmission. Therefore, to minimize the data volume of the message body, the first node device can perform deduplication on the n message contents and record the deduplicated message contents and the mapping relationship between each message content and the n cross-chain messages in the message body of the next-level aggregated message. It is understood that after deduplication, the actual number of message contents recorded in the message body of the next-level aggregated message is less than n, thereby reducing the data volume of the message body. Meanwhile, because it also records the mapping relationship between each message content and the n cross-chain messages, the next-hop node device can still accurately know the corresponding n message contents based on the mapping relationship and the actual recorded message contents. Therefore, it can still be assumed that the message body of the next-level aggregated message contains the n message contents.

[0115] In the above embodiments, for n (n≥2) message contents to be transmitted from a source subnet node in the source blockchain subnet to a corresponding target subnet node, the first node device can be any node device traversed by the forwarding path of these message contents. This node device can determine the n forwarding paths corresponding one-to-one with the n message contents. Furthermore, if it is determined that it (i.e., the first node device) has the same next-hop node device on the n forwarding paths, the next-level aggregated message constructed based on the n message contents will be forwarded to that next-hop node device.

[0116] It is understandable that any message content will be forwarded sequentially by each node device on its corresponding forwarding path until the last node device. For the n forwarding paths corresponding to the n message contents, the first node device has the same next-hop node device on all n forwarding paths, indicating that the first node device needs to transmit all n message contents to that next-hop node device. In this case, by constructing a next-level aggregated message based on the n message contents, and having the first node device forward this aggregated message to the next-hop node device, the aggregated transmission of these n message contents is achieved. In other words, the first node device only needs to forward one message (i.e., the aggregated message) to transmit all n message contents to the next-hop node device at once. Compared to related technologies that require forwarding n cross-chain messages containing corresponding message contents separately, this significantly reduces the number of messages the first node device needs to forward. As can be seen, in scenarios where source subnet nodes in the source blockchain subnet send cross-chain messages to target subnet nodes in the target blockchain subnet through network connections between node devices, this solution can aggregate multiple cross-chain messages according to the forwarding path to reduce the actual number of messages that need to be forwarded between node devices. This helps to avoid network congestion or even failures caused by an excessive number of messages, thereby improving the forwarding efficiency of cross-chain messages and enhancing the stability of the blockchain system.

[0117] As mentioned earlier, each node device deploys a mainnet node, and these mainnet nodes are connected by corresponding network links, such as the consensus link and synchronization link. Based on this, the first node device can forward the next-level aggregated message to the next-hop node device through the network link established between the mainnet node on the first node device and the mainnet node on the next-hop node device. This network link can be established between a communication plugin running on the first node device and a communication plugin running on the next-hop node device; wherein, the mainnet node on the same node device can share the communication plugin running on that node device with the subnet node, and this communication plugin can be, for example, the aforementioned P2P plugin. As described in the aforementioned cross-chain interaction scheme, by utilizing the network connection links (including consensus links and synchronization links) established between the mainnet nodes in the blockchain mainnet, the target blockchain subnet and the source blockchain subnet do not need to establish new network connection links. Instead, they can achieve network communication between the source subnet node and the target subnet node through the network connection links pre-established by the underlying blockchain mainnet. Understandably, at this point, the message content is actually transmitted between different node devices through the network connection links of the blockchain mainnet. Since any two mainnet nodes in the blockchain mainnet are reachable, this method can ensure that the message content can be reliably transmitted to the target subnet node.

[0118] After transmitting any message content or a cross-chain message containing any message content to the corresponding target subnet node using the aforementioned method, the target subnet node can respond to the received message content by performing pre-defined processing on the message content. For example, it can respond to the message content's request to query on-chain data, participate in consensus, or participate in privacy computation. And / or, the target subnet node can also synchronize the message content or the processing result of the pre-defined processing of the message content to other subnet nodes in its own blockchain subnet. The pre-defined processing can be encryption / decryption, consensus, privacy computation, etc., in a pre-defined manner, and this specification does not limit this.

[0119] Furthermore, any message content described in this specification can be encrypted by the source subnet node using the public key of the corresponding target subnet node. Alternatively, when the message content data volume is large, to maximize the efficiency of encryption / decryption processing, a data envelope method can be used for encryption. For example, any message content can be encrypted using a symmetric key, and the symmetric key can be encrypted using the public key of the target subnet node corresponding to the message content to obtain the key ciphertext. The encrypted message content and the key ciphertext are then included together in the message body and transmitted to the target subnet node so that it can decrypt it using its own private key. This will not be elaborated further.

[0120] Corresponding to the cross-subnet interaction method described in the above embodiments, this specification also proposes a blockchain system, which consists of a blockchain mainnet and multiple blockchain subnets it manages. Each subnet node in a blockchain subnet corresponds to a mainnet node deployed in its corresponding node device. The first node device where any mainnet node resides is used for:

[0121] For n message contents to be transmitted from a source subnet node to a corresponding target subnet node, determine n forwarding paths corresponding to the n message contents, wherein the target blockchain subnet where any target subnet node is located is different from the source blockchain subnet, and n≥2;

[0122] If it is determined that the first node device has the same next-hop node device on the n forwarding paths, then the next-level aggregated message constructed based on the n message contents will be forwarded to that next-hop node device.

[0123] The operation of the source blockchain node and the first node device can be found in the description of the aforementioned embodiments, and will not be repeated here.

[0124] Figure 6 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 6At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, memory 608, and non-volatile memory 610, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, such as the processor 602 reading the corresponding computer program from the non-volatile memory 610 into memory 608 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.

[0125] like Figure 7 As shown, Figure 7 This is a block diagram of a cross-subnet interaction device provided in this specification according to an exemplary embodiment, which can be applied to, for example... Figure 6 The device shown implements the technical solution of this specification; the device is applied to a blockchain system consisting of a blockchain mainnet and multiple blockchain subnets managed by it, wherein subnet nodes in the blockchain subnets correspond to the mainnet nodes deployed in their respective node devices; the device includes:

[0126] The path determination unit 701 is used to determine n forwarding paths corresponding to the n message contents to be transmitted from the source subnet node in the source blockchain subnet to the corresponding target subnet node by the first node device, wherein the target blockchain subnet where any target subnet node is located is different from the source blockchain subnet, and n≥2;

[0127] The aggregation forwarding unit 702 is used to forward the next-level aggregated message constructed based on the n message contents to the next-hop node device if the first node device determines that it has the same next-hop node device on the n forwarding paths.

[0128] Optionally, if the first node device is the source node device where the source subnet node is located, the n message contents and the n forwarding paths are determined by the first node device.

[0129] Optionally, if the first node device is not the source node device of the source subnet node, the n message contents are recorded in the message body of the previous-level aggregated message received by the first node device.

[0130] Optionally, the path determination unit 701 is specifically used for:

[0131] The first node device determines n forwarding paths corresponding to the n message contents based on the path information recorded in the message header of the upper-level aggregated message. The path information is generated by the source subnet node based on the n forwarding paths it has determined.

[0132] Optionally, the source node device where the source subnet node is located maintains the network topology structure between the node devices where each mainnet node in the blockchain mainnet is located, and the device further includes:

[0133] Initial path determination unit 703 is used to determine the forwarding path corresponding to any message content by the source subnet node; specifically, it is used for:

[0134] Determine any target subnet node corresponding to any message content and any target node device in which it resides;

[0135] Based on the network topology, determine the forwarding path with the fewest total hops between the source node device and any target node device, and use this path as the forwarding path corresponding to any message content; or...

[0136] If the source node device also maintains network latency information corresponding to the network topology, the forwarding path with the minimum total latency between the source node device and any target node device is determined from the network topology based on the network latency information, and this path is used as the forwarding path corresponding to any message content.

[0137] Optionally, when determining the forwarding path based on the network latency information, the network latency information includes:

[0138] Link delay of network links in the network topology; and / or,

[0139] The node latency of node devices in the network topology when forwarding messages.

[0140] Optionally, the upper-level aggregated message contains a total of S message contents.

[0141] The aggregation forwarding unit 702 is specifically used for: if the first node device determines that all n message contents need to be forwarded and n=S, then in response to having the same next-hop node device on the n forwarding paths, it forwards the upper-level aggregated message as the lower-level aggregated message to the next-hop node device.

[0142] The device further includes:

[0143] The message sending unit 704 is configured to determine, from the S message contents, that the destination of the corresponding forwarding path is the m1 message contents of the first node device, and in response to m1>0, send the m1 message contents to the corresponding target subnet nodes deployed locally; and,

[0144] The non-aggregated forwarding unit 705 is used to determine m2 message contents from the S message contents by the first node device. The next-hop node device on the forwarding path corresponding to any message content in the m2 message contents is different from the next-hop node device on the forwarding path corresponding to any other message content contained in the previous-level aggregated message. In response to m2>0, the first node device includes the m2 message contents in cross-chain messages and forwards them to the corresponding next-hop node devices.

[0145] Optional, also includes:

[0146] The content processing unit 706 is used to perform preset processing on any message content received by any target subnet node in response to receiving any message content; and / or synchronize the message content or the processing result of the preset processing of the message content to other subnet nodes in its own blockchain subnet.

[0147] Optionally, the aggregation forwarding unit 702 is specifically used for:

[0148] The next-level aggregated message is forwarded to the next-hop node device through the network link established between the main network node on the first node device and the main network node on the next-hop node device.

[0149] Optionally, the network link is established between the communication plugin running on the first node device and the communication plugin running on the next-hop node device; wherein, the main network node and the subnet node on the same node device share the communication plugin running on the node device.

[0150] Optional, also includes:

[0151] The aggregation message construction unit 707 is used by the first node device to construct the next-level aggregation message based on the n message contents; specifically, it is used for:

[0152] The n message contents are deduplicated, and the deduplicated message contents and the mapping relationship between each message content and the n cross-chain messages are recorded in the message body of the next-level aggregated message.

[0153] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0154] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0155] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this invention does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0156] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, 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, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes the elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0157] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0158] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0159] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0160] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0162] 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.

[0163] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, 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, graphene 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.

[0164] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0165] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules can reside in local and remote computer storage media, including storage devices.

[0166] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0167] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.

Claims

1. A cross-subnet interaction method, applied to a blockchain system consisting of a main blockchain network and multiple blockchain subnets managed by it, wherein subnet nodes in the blockchain subnets correspond to the main network nodes deployed in their respective node devices; the method includes: For n message contents to be transmitted from a source subnet node in a source blockchain subnet to a corresponding target subnet node, the first node device determines n forwarding paths corresponding to the n message contents, including: determining n forwarding paths corresponding to the n message contents based on the path information corresponding to the n message contents recorded in the message header of the upper-level aggregated message, wherein the path information is generated by the source subnet node based on the n forwarding paths determined by itself; wherein the n message contents are independent of each other, the target blockchain subnet where any target subnet node is located is different from the source blockchain subnet, n≥2, and when the first node device is not the source node device where the source subnet node is located, the n message contents are recorded in the message body of the upper-level aggregated message received by the first node device, wherein the upper-level aggregated message contains a total of S message contents; If a first node device determines that it has the same next-hop node device on the n forwarding paths, it forwards the next-level aggregated message constructed based on the n message contents to the next-hop node device, including: if the first node device determines that all the n message contents need to be forwarded and n=S, in response to having the same next-hop node device on the n forwarding paths, it forwards the previous-level aggregated message as the next-level aggregated message to the next-hop node device.

2. According to the method of claim 1, when the first node device is the source node device where the source subnet node is located, the n message contents and the n forwarding paths are determined by the first node device.

3. The method according to claim 1 or 2, wherein the source node device where the source subnet node is located maintains the network topology structure between the node devices where each mainnet node in the blockchain mainnet is located, and the source subnet node determines the forwarding path corresponding to any message content, including: Determine any target subnet node corresponding to any message content and any target node device in which it resides; Based on the network topology, determine the forwarding path with the fewest total hops between the source node device and any target node device, and use it as the forwarding path corresponding to any message content. or, If the source node device also maintains network latency information corresponding to the network topology, the forwarding path with the minimum total latency between the source node device and any target node device is determined from the network topology based on the network latency information, and this path is used as the forwarding path corresponding to any message content.

4. The method according to claim 3, wherein when determining the forwarding path based on the network delay information, the network delay information includes: Link latency of network links in the network topology; And / or, The node latency of node devices in the network topology when forwarding messages.

5. The method according to claim 1, further comprising: In the S message contents, m1 message contents whose destination is the first node device are determined as the destination of the corresponding forwarding path. In response to m1>0, at least a portion of the message contents are sent to the corresponding target subnet nodes deployed locally. Alternatively, in response to m1>0, the cross-chain message containing at least a portion of the message contents is sent to the subnet nodes of the target blockchain subnet deployed locally, so that the subnet nodes forward the cross-chain message to the corresponding target subnet nodes in the target blockchain subnet in which they are located. Among the S message contents, m2 message contents are determined. The next-hop node device of the first node device on the forwarding path corresponding to any message content in the m2 message contents is different from the next-hop node device on the forwarding path corresponding to any other message content contained in the previous-level aggregated message. In response to m2>0, the m2 message contents are respectively included in the cross-chain message and forwarded to the corresponding next-hop node device.

6. The method according to claim 5, further comprising: Any target subnet node responds to receiving any message content by performing a preset processing on the message content; And / or synchronize any message content or the processing result of preset processing of any message content to other subnet nodes in its own blockchain subnet.

7. The method according to claim 1, wherein the first node device forwards the next-level aggregation message to the next-hop node device, comprising: The next-level aggregated message is forwarded to the next-hop node device through the network link established between the main network node on the first node device and the main network node on the next-hop node device.

8. The method according to claim 7, wherein the network link is established between the communication plugin running on the first node device and the communication plugin running on the next-hop node device; wherein, The main network node and subnet node on the same node device share the communication plugin running on that node device.

9. The method according to claim 1, wherein the first node device constructs the next-level aggregated message based on the n message contents, comprising: The n message contents are deduplicated, and the deduplicated message contents and the mapping relationship between each message content and the n cross-chain messages are recorded in the message body of the next-level aggregated message.

10. A blockchain system, comprising a mainnet and multiple subnets managed by it, wherein subnet nodes in a subnet correspond to mainnet nodes deployed in their respective node devices; wherein, The first node device of any main network node is used for: For n message contents to be transmitted from a source subnet node in a source blockchain subnet to a corresponding target subnet node, n forwarding paths corresponding to the n message contents are determined. Specifically, this is done by: determining n forwarding paths corresponding to the n message contents based on the path information recorded in the message header of the upper-level aggregated message, wherein the path information is generated by the source subnet node based on the n forwarding paths it has determined; wherein the n message contents are independent of each other, the target blockchain subnet where any target subnet node is located is different from the source blockchain subnet, n≥2, and when the first node device is not the source node device where the source subnet node is located, the n message contents are recorded in the message body of the upper-level aggregated message received by the first node device, wherein the upper-level aggregated message contains a total of S message contents; If it is determined that the first node device has the same next-hop node device on the n forwarding paths, then the next-level aggregated message constructed based on the n message contents will be forwarded to the next-hop node device. Specifically, if the first node device determines that all n message contents need to be forwarded and n=S, then in response to having the same next-hop node device on the n forwarding paths, it will forward the previous-level aggregated message as the next-level aggregated message to the next-hop node device.

11. A cross-subnet interaction device, applied to a blockchain system consisting of a main blockchain network and multiple blockchain subnets managed by it, wherein subnet nodes in the blockchain subnets correspond to the main network nodes deployed in their respective node devices; the device comprises: A path determination unit is used to determine n forwarding paths corresponding to n message contents to be transmitted from a source subnet node in a source blockchain subnet to a corresponding target subnet node. This includes: determining n forwarding paths corresponding to the n message contents based on path information recorded in the message header of the upper-level aggregated message; the path information is generated by the source subnet node based on the n forwarding paths it has determined; wherein the n message contents are independent of each other, the target blockchain subnet of any target subnet node is different from the source blockchain subnet, n≥2, and when the first node device is not the source node device of the source subnet node, the n message contents are recorded in the message body of the upper-level aggregated message received by the first node device; the upper-level aggregated message contains a total of S message contents. An aggregation forwarding unit is used to forward a next-level aggregated message constructed based on the n message contents to a next-hop node device if the first node device determines that it has the same next-hop node device on the n forwarding paths. The unit includes: if the first node device determines that all the n message contents need to be forwarded and n=S, in response to having the same next-hop node device on the n forwarding paths, it forwards the previous-level aggregated message as the next-level aggregated message to the next-hop node device.

12. An electronic device, comprising: processor; Memory used to store processor-executable instructions; The processor implements the method as described in any one of claims 1-9 by executing the executable instructions.

13. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-9.

Images