CN115134075A

CN115134075A - Cross-subnet calling method and device, electronic equipment and storage medium

Info

Publication number: CN115134075A
Application number: CN202210759288.5A
Authority: CN
Inventors: 黄祖城
Original assignee: Ant Blockchain Technology Shanghai Co Ltd
Current assignee: Ant Blockchain Technology Shanghai Co Ltd
Priority date: 2022-06-29
Filing date: 2022-06-29
Publication date: 2022-09-30
Also published as: WO2024001022A1

Abstract

The specification provides a cross-subnet calling method, a cross-subnet calling device, an electronic device and a storage medium, wherein the method is applied to a first subnet node in a first block chain subnet managed by a block chain main network, the first subnet node maintains a first trusted execution environment, the block chain main network also manages a second block chain subnet, and a second subnet node in the second block chain subnet maintains a second trusted execution environment; the method comprises the following steps: running a first intelligent contract in a first trusted execution environment to generate a cross-subnet request and encrypting the cross-subnet request to obtain an encryption request; sending the encryption request to the second subnet node, and receiving an encryption response returned by the second subnet node, wherein the encryption response is obtained by the second subnet node through the following modes: reading the encryption request into a second trusted execution environment, decrypting to obtain a cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting to obtain an encryption response; and reading the encrypted response into the first trusted execution environment, and decrypting to obtain the cross-subnet response.

Description

Cross-subnet calling method and device, electronic equipment and storage medium

Technical Field

The embodiment of the specification belongs to the technical field of block chains, and particularly relates to a cross-subnet calling method, a cross-subnet calling device, electronic equipment and a storage medium.

Background

A block chain (Blockchain) is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. In the block chain system, data blocks are combined into a chain data structure in a sequential connection mode according to a time sequence, and a distributed account book which is not falsifiable and counterfeitable is ensured in a cryptographic mode. Because the blockchain has the characteristics of decentralization, information non-tampering, autonomy and the like, the blockchain is also paid more and more attention and is applied by people.

In some blockchain networks, there is sometimes a need for some nodes to implement small-scale transactions to avoid other nodes from obtaining these transactions and their related data, which can be achieved by further establishing blockchain subnets on the basis of blockchain main networks. Under the scene that a plurality of block chain sub-networks are established in a block chain main network, the demands of cross-sub-network calling are met among different block chain sub-networks.

Disclosure of Invention

The invention aims to provide a cross-subnet calling method, a cross-subnet calling device, electronic equipment and a storage medium.

According to a first aspect of one or more embodiments of the present specification, a cross-subnet calling method is provided, which is applied to a first subnet node in a first blockchain subnet managed by a blockchain master network, where the first subnet node maintains a first trusted execution environment, the blockchain master network also manages a second blockchain subnet, and a second subnet node in the second blockchain subnet maintains a second trusted execution environment; the method comprises the following steps:

running a first intelligent contract in a first trusted execution environment to generate a cross-subnet request, and encrypting the cross-subnet request based on a first public key corresponding to a second trusted execution environment in the first trusted execution environment to obtain an encryption request;

sending the encryption request to a second subnet node, and receiving an encryption response returned by the second subnet node, wherein the encryption response is obtained by the second subnet node through the following modes: reading the encryption request into a second trusted execution environment, decrypting the encryption request based on a first private key corresponding to the second trusted execution environment in the second trusted execution environment to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain the encryption response;

and reading the encrypted response into a first trusted execution environment, and decrypting the encrypted response in the first trusted execution environment based on a second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

According to a second aspect of one or more embodiments of the present specification, a cross-subnet calling method is provided, which is applied to a second subnet node in a second blockchain subnet managed by a blockchain master network, where the second subnet node maintains a second trusted execution environment, the blockchain master network also manages a first blockchain subnet, and a first subnet node in the first blockchain subnet maintains a first trusted execution environment; the method comprises the following steps:

receiving an encryption request obtained by encrypting a cross-subnet request by a first subnet node in a first trusted execution environment based on a first public key corresponding to a second trusted execution environment, wherein the cross-subnet request is generated by running a first intelligent contract in the first trusted execution environment by the first subnet node;

reading the encryption request into a second trusted execution environment, decrypting the encryption request based on a first private key corresponding to the second trusted execution environment in the second trusted execution environment to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain an encryption response;

and sending the encrypted response to the first subnet node, so that the first subnet node reads the received encrypted response into the first trusted execution environment, and decrypting the encrypted response in the first trusted execution environment based on a second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

According to a third aspect of one or more embodiments of the present specification, a cross-subnet calling apparatus is provided, which is applied to a first subnet node in a first blockchain subnet managed by a blockchain master network, where the first subnet node maintains a first trusted execution environment, the blockchain master network also manages a second blockchain subnet, and a second subnet node in the second blockchain subnet maintains a second trusted execution environment; the device comprises:

the encryption request acquisition unit is used for running a first intelligent contract in a first trusted execution environment to generate a cross-subnet request, and encrypting the cross-subnet request based on a first public key corresponding to a second trusted execution environment in the first trusted execution environment to obtain an encryption request;

an encryption request sending unit, configured to send the encryption request to the second subnet node, and receive an encryption response returned by the second subnet node, where the encryption response is obtained by the second subnet node through the following manner: reading the encryption request into a second trusted execution environment, decrypting the encryption request based on a first private key corresponding to the second trusted execution environment in the second trusted execution environment to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain the encryption response;

and the encrypted response decryption unit is used for reading the encrypted response into the first trusted execution environment, and decrypting the encrypted response in the first trusted execution environment based on a second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

According to a fourth aspect of one or more embodiments of the present specification, a cross-subnet calling apparatus is provided, which is applied to a second subnet node in a second blockchain subnet managed by a blockchain master network, where the second subnet node maintains a second trusted execution environment, the blockchain master network also manages a first blockchain subnet, and a first subnet node in the first blockchain subnet maintains a first trusted execution environment; the device comprises:

an encryption request receiving unit, configured to receive an encryption request obtained by encrypting a sub-network crossing request based on a first public key corresponding to a second trusted execution environment in a first trusted execution environment by a first sub-network node, where the sub-network crossing request is generated by running a first intelligent contract in the first trusted execution environment by the first sub-network node;

the encryption response obtaining unit is used for reading the encryption request into a second trusted execution environment, decrypting the encryption request based on a first private key corresponding to the second trusted execution environment in the second trusted execution environment to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain an encryption response;

and the encrypted response sending unit is used for sending the encrypted response to the first subnet node so that the first subnet node reads the received encrypted response into the first trusted execution environment, and the encrypted response is decrypted in the first trusted execution environment based on a second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

According to a fifth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

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

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

In this embodiment of the present specification, the first subnet node and the second subnet node are respectively located in different block chain subnets, and in a case of performing a cross-subnet call between the first subnet node and the second subnet node, by respectively maintaining corresponding trusted execution environments at the first subnet node and the second subnet node, security of the first subnet node and the second subnet node in a node operation process can be ensured, and each other can perform encrypted transmission on a cross-subnet request or a cross-subnet response through a public key corresponding to the trusted execution environment where the other is located, thereby ensuring security of a cross-subnet communication process, and the security of the node operation process and the security of the cross-subnet communication process are mutually matched, and finally, system-level security of the whole cross-subnet call process is achieved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings needed to be used in the description of the embodiments will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments described in the present disclosure, and it is obvious for a person skilled in the art to obtain other drawings based on these drawings without inventive labor.

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

FIG. 2 is a flow diagram of a cross-subnet calling method provided by an exemplary embodiment.

FIG. 3 is an application scenario diagram of a cross-subnet call method provided by an exemplary embodiment.

FIG. 4 is a diagram of an application scenario for another cross-subnet call method provided by an exemplary embodiment.

FIG. 5 is a flow chart of another cross-subnet call method provided by an exemplary embodiment.

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

Fig. 7 is a block diagram of a cross subnet invocation apparatus provided by an exemplary embodiment.

Fig. 8 is a block diagram of another cross-subnet invocation apparatus provided by an exemplary embodiment.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.

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

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

The process of quickly establishing the block chain sub-network based on the block chain main network comprises the following steps: the method comprises the steps that each block chain link point in a block chain main network respectively obtains a transaction for building a block chain sub-network, the transaction comprises configuration information of the block chain sub-network, the configuration information comprises identity information of node members participating in building the block chain sub-network, each block chain link point in the block chain main network respectively executes the transaction to reveal the configuration information, and when the configuration information comprises the identity information of a node member corresponding to a first block chain link point, node equipment for deploying the first block chain node starts a second block chain node belonging to the block chain sub-network on the basis of an innovation block comprising the configuration information.

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

When the blockchain sub-network is constructed on the basis of the blockchain main network, it is easy to understand that a logical hierarchical relationship exists between the blockchain sub-network and the blockchain main network. For example, when building a blockchain subnet1 on subnet0 shown in fig. 1, subnet0 may be considered to be at a first level and subnet1 may be considered to be at a second level. In one case, the blockchain master in this specification may be an underlying blockchain network, that is, the blockchain master is not a blockchain slave established on the basis of other blockchain networks, for example, the subnet0 in fig. 1 may be considered as a blockchain master belonging to an underlying blockchain network type. In another case, the blockchain master in this specification may also be a subnet of another blockchain network, for example, another blockchain subnet may be further configured on the basis of the subnet1 in fig. 1, and at this time, the subnet1 may be considered as the blockchain master corresponding to the blockchain subnet, and this does not affect that the subnet1 belongs to the blockchain subnet created on the subnet0 at the same time. It can be seen that the blockchain main network and the blockchain sub-network are actually relative concepts, and the same blockchain network may be the blockchain main network in some cases and the blockchain sub-network in other cases.

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

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

The identity information of the node member may include a public key of the node, or other information capable of representing the identity of the node, such as a node ID, which is not limited in this specification. Taking a public key as an example, each blockchain node has one or more corresponding sets of public-private key pairs, and the private key is held by the blockchain node and the public key is public and uniquely corresponds to the private key, so that the identity of the corresponding blockchain node can be characterized by the public key. Therefore, for blockchain nodes that are desired to be node members of a blockchain subnet, the public keys of these blockchain nodes can be added to the transaction of the building blockchain subnet as the identity information of the node members. The public and private key pair can be used for signature verification. For example, in a signed consensus algorithm, such as the sub net1, the above-mentioned nodeB1 signs a message with its own private key, and broadcasts the signed message in the sub net1, and nodeB1, nodeB c1 and nodeB1 can verify the signature of the received message with the public key of nodeB1 to confirm that the received message is indeed from nodeB1 and has not been tampered with.

The first master network node may be a blockchain node on the blockchain master network that belongs to a node member indicated by the configuration information. When the blockchain subnet is constructed, the first master network node does not directly participate in the construction of the blockchain subnet and becomes a node member thereof, but the first subnet node needs to be generated by the node device for deploying the first master network node and becomes a node member in the blockchain subnet by the first subnet node. The first main network node and the first sub-network node correspond to the same blockchain member, for example, correspond to the same alliance chain member in an alliance chain scene, but the first main network node belongs to a blockchain main network and the first sub-network node belongs to a blockchain sub-network, so that the blockchain member can participate in the transaction of the blockchain main network and the blockchain sub-network respectively; moreover, because the blockchain main network and the blockchain sub-network belong to two mutually independent blockchain networks, the blocks generated by the first main network node and the blocks generated by the first sub-network node are respectively stored in different storages (the adopted storages can be databases, for example) on the node device, so that mutual isolation between the storages used by the first main network node and the first sub-network node respectively is realized, and thus, data generated by the blockchain sub-network can only be synchronized among the node members of the blockchain sub-network, so that the blockchain members only participating in the blockchain main network cannot obtain the data generated by the blockchain sub-network, the data isolation between the blockchain main network and the blockchain sub-network is realized, and the transaction requirements between partial blockchain members (namely, the blockchain members participating in the blockchain sub-network) are met.

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

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

In addition to the identity information of the node members described above, the configuration information may include at least one of: the network identifier of the blockchain subnet, the identity information of an administrator of the blockchain subnet, the attribute configuration for the blockchain platform code, and the like, which are not limited in this specification. The network identifier is used to uniquely characterize the blockchain subnet, and thus the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets established on the blockchain main network. Identity information of an administrator of the blockchain subnet, such as a public key of a node member as the administrator; the administrators of the blockchain main network and the blockchain sub-network may be the same or different.

One of the advantages of building the blockchain subnet by using the blockchain master network is that since the first master network node is already deployed on the node device generating the first subnet node, the blockchain platform code used by the first master network node can be multiplexed on the first subnet node, so that repeated deployment of the blockchain platform code is avoided, and the building efficiency of the blockchain subnet is greatly improved. Then, if the configuration information does not include the attribute configuration for the blockchain platform code, the first subnet node may reuse the attribute configuration adopted on the first master network node; if the configuration information includes the attribute configuration for the blockchain platform code, the first subnet node may adopt the attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited to the attribute configuration of the first host node and is not related to the first host node. The attribute configuration for blockchain platform code may include at least one of: code version number, whether consensus is required, type of consensus algorithm, block size, etc., which is not limited in this specification.

The transactions that make up the blockchain subnet include transactions that invoke contracts. The transaction may specify the address of the invoked smart contract, the method invoked, and the incoming parameters. For example, the contract invoked may be the aforementioned startup contract or system contract, the method invoked may be a method that builds a blockchain subnet, and the incoming parameters may include the configuration information described above. In one embodiment, the transaction may contain the following information:

from：Administrator

to：Subnet

method：AddSubnet(string)

string：genesis

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

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

After executing a transaction that invokes an intelligent contract, a node in the blockchain network generates a corresponding receipt (receipt) for recording information related to executing the intelligent contract. In this way, information about the contract execution results may be obtained by querying the receipt of the transaction. The contract execution result may be represented as an event (event) in the receipt. The message mechanism can implement message passing through events in the receipt to trigger the blockchain node to execute corresponding processing. The structure of the event may be, for example:

Event：

[topic][data]

......

in the above example, the number of events may be one or more; wherein, each event respectively comprises fields of a subject (topic) and data (data). The tile chain node may perform the preset process by listening to topic of the event, in case that predefined topic is listened to, or read the related content from the data field of the corresponding event, and may perform the preset process based on the read content.

In the event mechanism, it is equivalent to that there is a client with a snooping function at a snooping party (for example, a user with a snooping requirement), for example, an SDK or the like for implementing the snooping function is run on the client, and the client snoops an event generated by a blockchain node, and the blockchain node only needs to generate a receipt normally. The passage of transaction information may be accomplished in other ways than through the event mechanism described above. For example, the monitoring code can be embedded in a blockchain platform code running at blockchain nodes, so that the monitoring code can monitor one or more data of transaction content of blockchain transactions, contract states of intelligent contracts, receipts generated by contracts and the like, and send the monitored data to a predefined monitoring party. Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in a development process, or may be embedded by a monitoring party based on a requirement of the monitoring party, which is not limited in this specification.

It can be seen that the execution result of the Subnet contract may include the configuration information, and the execution result may be in the receipt as described above, and the receipt may contain the event related to the execution of the AddSubnet () method, i.e., the networking event. The topoc of a networking event may contain a predefined networking event identification to distinguish it from other events. For example, in an event related to the execution of the AddSubnet () method, the content of topic is a keyword subnet, and the keyword is distinguished from topic in the event generated by other methods. Then, nodeb to nodeb can determine to listen to an event related to execution of the AddSubnet () method, that is, a networking event, by listening to topic included in each event in the generated receipt, in the case where topic including the keyword subnet is listened to. For example, the events in the receipt are as follows:

Event：

[topic:other][data]

[topic:subnet][data]

......

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

{subnet1；

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

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

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

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

}

where subnet1 is the network identification of the blockchain subnet that one wishes to create. Each blockchain link point in the blockchain master network may record network identifiers of all blockchain subnets that have been created on the blockchain master network, or other information related to the blockchain subnets, which may be maintained in the Subnet contract, for example, and may specifically correspond to values of one or more contract states included in the Subnet contract. Then, nodeA to nodeE may determine whether the subnet1 already exists according to the recorded network identifiers of all the blockchain subnets that have been created; if not, subnet1 is the new blockchain subnet that needs to be created currently, and if so, subnet1 is already present.

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

Besides the network identification subnet1, the data field also contains the identity information of each node member. The node device deploying the first master network node may monitor the generated receipt, and obtain, by the node device deploying the first master network node, configuration information or an innovation block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first master network node belongs to the node member. Or the first block link point may monitor the generated receipt, and trigger the node device deploying the first block link node to acquire the configuration information or the created block included in the networking event when the networking event is monitored and the content of the networking event indicates that the first block link point belongs to the node member.

As previously described, the node device may listen for receipts directly. Assuming that nodeA-nodeE are respectively deployed on the node devices 1-5, and the node devices 1-5 can monitor receipts respectively generated by the nodeA-nodeE, under the condition that the subnet1 is monitored to be a block chain subnet needing to be newly established, the node devices 1-5 further identify the identity information of the node members contained in the data field to determine the processing mode of the node devices. Take nodeA and node device 1 as an example: if node device 1 finds that the data field contains identity information such as a public key, an IP address, and a port number of nodeA, node device 1 generates a created block containing configuration information when obtaining the configuration information from the data field based on the above-mentioned message mechanism, and node device 1 deploys nodeA1 locally, and further loads the generated created block by nodeA1, thereby becoming a subnet node of subnet 1; similarly, node device 2 may generate nodeB1, node device 3 may generate nodeB c1, and node device 4 may generate nodeB 1. And if the node device 5 finds that the identity information included in the data field does not match with itself, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a block link point in subnet 1.

As mentioned above, the blockchain link point in the blockchain master network can listen for the receipt and trigger the node device to perform the relevant processing according to the listening result. For example, when nodeA to nodeE determine that subnet1 is a blockchain subnet that needs to be newly created, identity information of node members included in the data field is further recognized to determine their own processing method. For example, nodeA-nodeD may find that the data field includes identity information such as their own public key, IP address, and port number, assuming nodeA-nodeD are respectively deployed on node devices 1-4, taking nodeA and node device 1 as an example: the nodeA triggers the node device 1, so that the node device 1 obtains the configuration information from the data field based on the message mechanism and generates a created block containing the configuration information, and the node device 1 deploys the nodeA1 locally, and the nodeA1 loads the generated created block, so that the node device 1 becomes 1 subnet node in the subnet 1; similarly, nodeB will trigger NodeB1 to be generated by node device 2, nodeC will trigger NodeC1 to be generated by node device 3, and nodeD will trigger NodeD1 to be generated by node device 4. And the nodeE finds that the identity information contained in the data field is not matched with the nodeE, and if the nodeE is deployed on the node device 5, the node device 5 does not generate a creation block according to the configuration information in the data field, and does not generate a node in the subnet 1.

As mentioned above, the first master network node and the first subnet node do not necessarily adopt the same identity information. Therefore, in the above embodiment, the data field may include the identity information generated in advance for nodeA 1-nodeD 1, and be distinguished from the identity information of nodeA-nodeD. Taking nodeA and node device 1 as an example: if identity information of nodeA1 is found in the data field, node device 1 may generate a founding block, deploy nodeA1, and load the founding block by nodeA 1; alternatively, nodeA, if identity information of nodeA1 is found in the data field, will trigger node device 1 to generate a foundational block, deploy nodeA1, and load the foundational block by nodeA 1. The processing modes of other blockchain nodes or node devices are similar, and are not described in detail herein.

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

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

By the method, the block chain sub-network can be created on the block chain main network. Taking fig. 1 as an example, the subnet0 originally includes nodeA to nodeE, and based on the subnet0, the subnet1 can be constructed, where the subnet1 includes nodeA1 to nodeD1, and nodeA1, nodeB and nodeB1, nodeC and nodeC1, and nodeD1 are respectively disposed on the same node device. Similarly, a subnet2 or more block chain subnets can be constructed on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA1, nodeA2, nodeB and nodeB1, nodeB2, nodeC1 and nodeC2, nodeD and nodeD1, and nodeE2 are respectively deployed on the same node device. And, the subnet1, subnet2, etc. may be used as a new blockchain main network, and a blockchain subnet may be further constructed on the basis of the new blockchain main network, which is similar to the construction of the subnet1 or subnet2, and is not described herein again. As can be seen, in the manner of initiating a transaction on the blockchain main network to select a node member to create a blockchain subnet, the subnet nodes of the newly created blockchain subnet can all be deployed on the node device where the main network node of the blockchain main network is located, that is, from the perspective of the slave node device, the node device where the subnet node of the blockchain subnet is located belongs to the subset of the node device where the main network node is located, in other words, the main network node in the blockchain main network is deployed on the node device where the subnet node of the blockchain subnet is located.

In addition to the above manner of initiating a transaction on the blockchain main network to select a node member to create a blockchain sub-network, the blockchain sub-network can also be created by other means and managed by the blockchain main network. For example, a block chain sub-network (hereinafter referred to as a registration networking mode for short) may be established on the block chain main network through a registration mode, and an existing block chain network is directly registered to the block chain main network, so that the newly registered block chain network is managed by the block chain main network, and the newly registered block chain network becomes the block chain sub-network of the block chain main network. By means of the registration networking mode, subnet information of a block chain subnet to be established is directly registered to a block chain main network, so that the block chain main network obtains relevant information of the block chain subnet to be established (by receiving and executing a transaction which is sent by the block chain network to be established and used for carrying out association storage on identity information of the block chain subnet to be established and a subnet identifier distributed to the block chain network to be established), such as a subnet identifier and an operation state of the block chain subnet to be established, wherein public keys and plug-in configuration information of each node member, IP addresses and port information of each node device and the like, the information can be written into a contract state of a system contract corresponding to the block chain main network, and therefore the block chain main network obtains a management right of the block chain subnet to be established, and after the registration is completed, the block chain subnet establishment is completed. Since the registration networking manner does not require designating node members on the blockchain master network to form blockchain subnets through transactions, subnet nodes in the blockchain subnetwork constructed through the registration networking manner may be completely or partially different from node devices disposed on nodes in the blockchain master network, for example, subnet0 in fig. 1 creates a subnet4 (not shown in fig. 1) in the registration networking manner, and assuming that the master nodes nodeA to nodeE included in the subnet0 themselves are disposed on node devices 1 to 5, respectively, then the subnet node corresponding to subnet4 may be disposed on any node device other than node devices 1 to 5, or one or more subnet nodes in subnet4 may be disposed on any node device in node devices 1 to 5, respectively (but it is still required to ensure that only one subnet node in sub 4 is disposed on one node device), while other subnet nodes in sub 4 are disposed on any node devices other than node devices 1 to 5, of course, the subnet nodes in subnet4 may all be deployed in node devices 1 to 5.

The cross-subnet calling method according to the present specification will be described in detail below with reference to fig. 2. FIG. 2 is a flow diagram of a cross-subnet calling method provided by an exemplary embodiment. The method is applied to a first subnet node in a first block chain subnet managed by a block chain main network, the first subnet node maintains a first trusted execution environment, the block chain main network also manages a second block chain subnet, and a second subnet node in the second block chain subnet maintains a second trusted execution environment; the method comprises the following steps:

s202: the method comprises the steps of running a first intelligent contract in a first trusted execution environment to generate a cross-subnet request, and encrypting the cross-subnet request in the first trusted execution environment based on a first public key corresponding to a second trusted execution environment to obtain an encryption request.

In this embodiment of the present specification, the first blockchain subnet and the second blockchain subnet are both created on the basis of the blockchain master network according to the manner of creating the blockchain subnet, where any blockchain subnet is managed by the blockchain master network, which may specifically be represented as follows: the block chain main network can realize management functions of node start and stop, network structure adjustment and the like of each block chain sub-network by calling a sub-network management contract deployed by the block chain main network.

The first subnet node maintains a first trusted execution environment, and can place the transaction execution, consensus process, contract execution and other computing tasks in the node operation process into the first trusted execution environment for execution, and in the process, the first subnet node can read ciphertext data outside the first trusted execution environment into the first trusted execution environment and then decrypt the ciphertext data into plaintext data for operation, so that the first subnet node can determine the security of the first subnet node on the node operation level by using the confidentiality of the first trusted execution environment. Similarly, the second subnet node also maintains a second trusted execution environment, which can also implement the security of the second subnet node at the node operation level by using the second trusted execution environment in the manner described above.

In this embodiment of the present specification, any subnet node in the first blockchain subnet or the second blockchain subnet may be deployed with a corresponding Trusted Execution Environment, and the security of the running layer of each node is implemented according to the above manner, in this scenario, the first blockchain subnet and the second blockchain subnet are referred to as a TEE (Trusted Execution Environment) chain.

When a first subnet node runs a first intelligent contract in a first trusted execution environment, the first intelligent contract may generate a cross-subnet call demand for other blockchain subnets, for example, a cross-subnet request directed to a second subnet node in a second blockchain subnet is generated, at this time, the cross-subnet request is required to be transmitted to the second subnet node and executed in response, and a cross-subnet response generated by the second subnet node executing the cross-subnet request is received. However, in order to ensure security in a transmission process outside the trusted execution environment (cross-subnet communication) of the cross-subnet request and the cross-subnet reply, it is necessary to perform the cross-subnet communication after performing encryption processing in the trusted execution environment in advance. Therefore, the first subnet node does not directly send the cross-subnet request generated by the first intelligent contract running in the first trusted execution environment to the second subnet node, but encrypts the cross-subnet request based on the first public key corresponding to the second trusted execution environment in the first trusted execution environment to obtain an encryption request, and then sends the encryption request to the second subnet node. In order to ensure that the encrypted request can be correctly routed to the second subnet node, a specific field in the original cross-subnet request is kept from being encrypted in the encryption process, for example, the identity information (IP address, node public key or other identity) of the second subnet node, the identity information of the second blockchain subnet, and the like.

In this embodiment of the present specification, the first trusted execution environment maintains a corresponding public-private key pair (a second public key and a second private key) to implement an encryption and decryption process of external data in the first trusted execution environment, where the second private key is solely held by the first trusted execution environment, and the second public key is disclosed to the outside. Similarly, the second trusted execution environment also maintains a corresponding public and private key pair (a first public key and a first private key) to realize the encryption and decryption process of external data in the second trusted execution environment, wherein the first private key is independently held by the second trusted execution environment, and the first public key is externally disclosed.

Therefore, after the cross-subnet request is encrypted in the first trusted execution environment based on the first public key corresponding to the second trusted execution environment to obtain the encryption request, the encryption request can only be decrypted in the second trusted execution environment maintained by the second subnet node uniquely holding the first private key theoretically, so that even if the encryption request is captured by a third party in the transmission process outside the trusted execution environment, the third party can not decrypt and restore the cross-subnet request to obtain a plaintext state due to the lack of the first private key, thereby ensuring the security of the cross-subnet communication process, and the encryption request belongs to a private transaction due to the fact that the encryption request has the properties and confidentiality of a block chain transaction at the same time.

In an embodiment of the present specification, the first intelligent contract is executed in the first trusted execution environment by the first subnet node by loading a first intelligent contract program in the first trusted execution environment, wherein the first intelligent contract program is obtained by the first subnet node decrypting a first intelligent contract program ciphertext read from outside the first trusted execution environment in the first trusted execution environment. The first intelligent contract runs in the first trusted execution environment, which is actually the result of the first subnet node loading the first intelligent contract program in the first trusted execution environment, and since the first trusted execution environment is essentially a segment of physically isolated execution environment, and all running programs are loaded in isolated memory, persistent storage is required for programs that do not need to run in the first trusted execution environment for a while. In order to ensure information security, the principle of "loading by decryption inside the trusted execution environment and storing by encryption outside the optional execution environment" is followed for any program running in the first trusted execution environment, so that the first smart contract program is essentially the result of decrypting the first smart contract program ciphertext read from outside the first trusted execution environment inside the first trusted execution environment, for example, the first smart contract program ciphertext is stored outside the first trusted execution environment by being encrypted by the first smart contract program through the second public key and can be decrypted into the first smart contract program through the second private key inside the first trusted execution environment, and a smart contract executed inside the trusted execution environment and stored by encryption outside the trusted execution environment like the first smart contract is called a privacy contract.

S204: sending the encryption request to a second subnet node, and receiving an encryption response returned by the second subnet node, wherein the encryption response is obtained by the second subnet node through the following modes: reading the encryption request into a second trusted execution environment, decrypting the encryption request in the second trusted execution environment based on a first private key corresponding to the second trusted execution environment to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain the encryption response.

After the first subnet node encrypts the cross-subnet request in the first trusted execution environment to obtain an encryption request, the encryption request can be sent to the second subnet node through cross-subnet communication.

The cross-subnet communication among the subnet nodes in different block chain subnets is mainly realized by network connection links which are pre-established among main network nodes deployed on node equipment where the nodes are located. Taking fig. 1 as an example, a node device 3 where a first subnet node nodeb1 in the first blockchain subnet1 is located is also deployed with a master node nodeb in the blockchain master network subnet0, and a node device 5 where a second subnet node nodeb2 in the second blockchain subnet2 is located is also deployed with a master node nodeb in the subnet 0. Assuming that nodeC1 wishes to send an encryption request to the third node 2, although there is no direct network connection link between subnet1 and subnet2 (between nodeC and node), since the network connection link implemented when subnet0 is formed has been established in advance between the nodeC deployed on node device 3 and the node deployed on node device 5, and the network connection link enables node device 3 and node device 5 to communicate with each other, nodeC1 can send an encryption request to node device 5 from node device 3, and finally node device 5 routes to its locally deployed node 2. In an embodiment, the network connection link implemented when the subnet0 is formed is a consensus link established between the master network nodes in the subnet0 for consensus on transactions and/or a synchronization link for synchronization of the tiles.

In the embodiment of the present specification, the master node and the sub-network node on the same node device share a blockchain communication plug-in running on the node device, such as a P2P (Peer-to-Peer) plug-in, the network connection link realized when the subnet0 is formed is specifically established by nodeC and nodeE respectively using P2P plug-ins on node device 3 and node device 5, since the P2P plug-in on a node device may be shared by various blockchain nodes on the node device, therefore, the nodeC1 in the subnet1 can call the P2P plug-in locally operated by the node device 3, establish a network connection with the P2P plug-in operated on the node device 5 to which the nodeE2 belongs by means of the network connection based on the P2P plug-in between the node device 3 and the node device 5 realized when the subnet0 is formed, thereby sending an encryption request to the node apparatus 5 to thereby further enable network communication with the node e 2. Therefore, a new network connection link does not need to be established between the first blockchain subnet and the second blockchain subnet, but the cross-subnet communication between the first subnet node in the first blockchain subnet and the second subnet node in the second blockchain subnet is realized through the network connection link pre-established by the bottom-layer blockchain main network.

After the second subnet node receives the encrypted response, the second subnet node reads the encrypted response into the second trusted execution environment maintained by the second subnet node, and decrypts the encrypted request in the second trusted execution environment based on the first private key corresponding to the second trusted execution environment to obtain the cross-subnet request. After obtaining the cross-subnet request, the second subnet node further executes the cross-subnet request in the second trusted execution environment to generate a corresponding cross-subnet response, for example, invokes a second intelligent contract running in the second trusted execution environment to execute the cross-subnet request to generate a cross-subnet response, that is, the cross-subnet response is generated by executing the cross-subnet request by a second intelligent contract running in the second trusted execution environment, and in a case that the cross-subnet request queries a specific contract state at a specific block height in the second intelligent contract, the cross-subnet response includes the corresponding specific contract state. After the second subnet node obtains the cross-subnet response, in consideration of cross-subnet communication security, the cross-subnet response is encrypted in the second trusted execution environment based on the second public key corresponding to the first trusted execution environment to obtain the encrypted response, and then the encrypted response is output to the second trusted execution environment and is returned to the first subnet node.

In an embodiment of the present specification, the second intelligent contract is run in the second trusted execution environment by the second subnet node by loading a second intelligent contract program in the second trusted execution environment, where the second intelligent contract program is obtained by the second subnet node decrypting a second intelligent contract program ciphertext read from outside the second trusted execution environment in the second trusted execution environment. The second intelligent contract runs in the second trusted execution environment, which is actually the result of the second subnet node loading the second intelligent contract program in the second trusted execution environment, and since the second trusted execution environment is essentially a segment of physically isolated execution environment, and all running programs are loaded in the isolated memory, persistent storage is required for programs that do not need to run in the second trusted execution environment for a while. In order to ensure information security, the principle of "loading by decryption inside the trusted execution environment and storing by encryption outside the optional execution environment" is followed for any program running in the second trusted execution environment, so that the second intelligent contract program is essentially the result of decryption inside the second trusted execution environment of the second intelligent contract program cryptograph read from outside the second trusted execution environment. For example, in the case that the second subnet node receives the encrypted message and decrypts the encrypted message in the second trusted execution environment to obtain the cross-subnet request, it is further found that the cross-subnet request is a cross-subnet request for invoking the second intelligent contract, so that the second subnet node can directly invoke the running second intelligent contract in the second trusted execution environment to execute the cross-subnet request, or read the second intelligent program cryptograph from the outside of the second trusted execution environment into the inside of the second trusted execution environment and decrypt the second intelligent contract through the first private key, temporarily load the second intelligent contract program in the second trusted execution environment, thereby implementing running the second intelligent contract in the second trusted execution environment, and finally invoke the running second intelligent contract to execute the cross-subnet request. Similar to the first intelligent contract, the second intelligent contract also belongs to a privacy contract.

The process of sending the encryption response to the first subnet node by the second subnet node is implemented based on the cross-subnet communication, similar to the process of sending the encryption request to the second subnet node by the first subnet node, and the detailed process is not described herein.

S206: and reading the encrypted response into a first trusted execution environment, and decrypting the encrypted response in the first trusted execution environment based on a second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

After receiving the encrypted response, the first subnet node may read the encrypted response into the first trusted execution environment, and decrypt the encrypted response in the first trusted execution environment using a second private key unique to the first trusted execution environment to obtain the cross-subnet response. So far, the embodiments of the present specification completely implement a process in which a first subnet node initiates a cross-subnet call to a second subnet node.

Optionally, the cross-subnet request includes: the subnet nodes in the second blockchain subnet participate in the executed common transaction together or the local transaction is executed only by the second subnet node independently.

In embodiments of the present specification, the cross-subnet request may be a consensus transaction or a local transaction. When the cross-subnet request is a consensus transaction, after the second subnet node receives the cross-subnet request, the cross-subnet request performs consensus, execution, blocking and uplink to the blockchain account book in the second blockchain subnet like a normal blockchain transaction, which means that all subnet nodes (including the second subnet node) in the second blockchain subnet execute the cross-subnet request to generate a corresponding cross-subnet response, and simultaneously, the world state of the second blockchain subnet is changed, and a corresponding cross-subnet response is returned by one of the enumerated subnet nodes (for example, the second subnet node).

The local transaction referred to in the embodiments of the present specification refers to a transaction that does not participate in blockchain consensus, blockchain, and uplink, and is only used as an internal calling medium; under the condition that the cross-subnet request is a local transaction, after the second subnet node receives the cross-subnet request, the second subnet node independently executes the cross-subnet request to generate a corresponding cross-subnet response, the world state is not known and changed, and the cross-subnet response is returned to the first subnet node in a callback mode only after the local execution is finished. Since the cross-subnet request as a local transaction does not need to be identified, blocked and linked, the embodiments of the present specification can limit the amount of computation inside the second subnet node, reduce the computation burden of the second blockchain network in response to the cross-subnet request as a whole, and improve the execution efficiency of the cross-subnet request.

Optionally, the first subnet node and the second subnet node are deployed in the same or different node devices.

As shown in fig. 3, fig. 3 is an application scenario diagram of the node c1 as a first subnet node and the node e2 as a second subnet node on the basis of fig. 1, and as an embodiment that the first subnet node and the second subnet node are deployed in different node devices, the node device 3 has a node c belonging to a subnet0, a node c1 belonging to a subnet1, and a node c2 belonging to a subnet2 deployed at the same time, where the node c, the node c1, and the node c2 are specifically block link point instances (hereinafter referred to as block link nodes) formed by the node device 3 running a pre-deployed block link platform code in a locally deployed virtual machine, and the node c is stored in a database corresponding to the node c as related data of the block link nodes during running, and the node c1 and the node c2 are stored in a database corresponding to the node c1 and a database corresponding to the node c2 as related data of other block link nodes during running. Similarly, the node device 5 is simultaneously deployed with nodes belonging to subnet0 and nodes 2 belonging to subnet 2. In addition, a blockchain consensus code can be deployed in any node device, and the node device can run the consensus code to form a consensus component instance locally; and, a P2P (Peer-to-Peer) component code managed in a plug-in form may also be deployed in the node device, and the node device may run the P2P component code to locally form a P2P component instance, that is, a P2P plug-in, for example, in fig. 3, both the node device 3 and the node device 5 locally run a P2P plug-in, and the P2P plug-in may be shared by different blockchain nodes on the same node device, for example, the nodeC, nodeC1, and nodeC2 in the node device 3 may call the same P2P plug-in running on the node device 3 to share functions and data thereof, for example, implement cross-subnet communication. The nodeC1 maintains a first trusted execution environment in which a first smart contract deployed by nodeC1 can run in plain text, and similarly, the nodeE2 maintains a second trusted execution environment in which a second smart contract deployed by nodeE2 can run in plain text. In this embodiment of the present specification, the cross-subnet communication between the first subnet node and the second subnet node is specifically communication of cross-node devices, and data transmitted by the cross-subnet communication may pass through other node devices besides the node devices where the first subnet node and the second subnet node are respectively located in the routing process.

As shown in fig. 4, fig. 4 is an application scenario diagram based on fig. 1, in which nodeb1 serves as a first subnet node and nodeb2 serves as a second subnet node, and as an embodiment in which the first subnet node and the second subnet node are deployed in the same node device, a nodeb 0 belonging to subnet0, a nodeb1 belonging to subnet1, and a nodeb2 belonging to subnet2 are deployed on a node device 3 at the same time, and the node device 3 runs a P2P plugin locally, and the P2P plugin can share data and functions by nodeb, nodeb1, and nodeb2 in the node device 3. In the embodiment of the present specification, a plurality of trusted execution environments (a first trusted execution environment and a second trusted execution environment) are maintained in the same node device (node device 3), the nodeb1 maintains the first trusted execution environment, the first smart contract deployed by nodeb1 can run in a clear text form in the first trusted execution environment, the nodeb2 also maintains the second trusted execution environment, and the second smart contract deployed by nodeb2 can run in a clear text form in the second trusted execution environment. In this embodiment of the present specification, the cross-subnet communication between the first subnet node and the second subnet node is specifically cross-process communication inside the node device, and data transmitted by the cross-subnet communication does not pass through other node devices except the node device where the first subnet node and the second subnet node are located together, but only passes through a P2P plug-in running locally on the node device, and flows between the first subnet node and the second subnet node.

Optionally, the method further includes: reading the cross-subnet transaction ciphertext into a first trusted execution environment, decrypting the cross-subnet transaction ciphertext in the first trusted execution environment to obtain a cross-subnet transaction, and calling a first intelligent contract to execute the cross-subnet transaction to generate the cross-subnet request.

In this specification embodiment, the first smart contract is the cross-subnet request generated in the case of executing a cross-subnet transaction, and the cross-subnet request is obtained by decrypting a cross-subnet transaction cryptogram read in from outside the first trusted execution environment inside the first trusted execution environment. Specifically, the transaction initiator may initiate a cross-subnet transaction ciphertext to the first blockchain network, where the cross-subnet transaction ciphertext is identified and executed by each subnet node (including the first subnet node) in the first blockchain network, and when the cross-subnet transaction ciphertext needs to be executed, the first subnet node needs to first read the cross-subnet transaction ciphertext into the first trusted execution environment for decryption (e.g., based on the second private key for decryption) to obtain the cross-subnet transaction, and then may directly call the running first smart contract in the first trusted execution environment to execute the cross-subnet transaction, or read the first smart program ciphertext from the outside of the first trusted execution environment into the inside of the first trusted execution environment and decrypt the first smart contract program by the first private key, and then temporarily load the first smart contract program in the first trusted execution environment to implement the running of the first smart contract in the first trusted execution environment, and finally, calling the first intelligent contract in the running state to execute the cross-subnet transaction to generate a cross-subnet request. Cross-subnet transactions to which embodiments of the present description relate pertain are private transactions.

FIG. 5 is a flow chart of another cross-subnet call method provided by an exemplary embodiment. The method is applied to a second subnet node in a second blockchain subnet managed by a blockchain master network, the second subnet node maintains a second trusted execution environment, the blockchain master network also manages a first blockchain subnet, and a first subnet node in the first blockchain subnet maintains a first trusted execution environment; the method comprises the following steps:

s502: and receiving an encryption request obtained by encrypting the cross-subnet request by the first subnet node in the first trusted execution environment based on the first public key corresponding to the second trusted execution environment, wherein the cross-subnet request is generated by running the first intelligent contract in the first trusted execution environment by the first subnet node.

S504: reading the encryption request into a second trusted execution environment, decrypting the encryption request in the second trusted execution environment based on a first private key corresponding to the second trusted execution environment to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain an encryption response.

S506: and sending the encrypted response to the first subnet node, so that the first subnet node reads the received encrypted response into the first trusted execution environment, and decrypting the encrypted response in the first trusted execution environment based on a second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

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

Fig. 6 is a block diagram of a cross-subnet calling apparatus provided in the present specification according to an exemplary embodiment, and the apparatus may be applied to the device shown in fig. 6 to implement the technical solution of the present specification; the device is applied to a first subnet node in a first blockchain subnet managed by a blockchain main network, the first subnet node maintains a first trusted execution environment, the blockchain main network also manages a second blockchain subnet, and a second subnet node in the second blockchain subnet maintains a second trusted execution environment; the device comprises:

an encryption request obtaining unit 701, configured to run a first intelligent contract in a first trusted execution environment to generate a sub-network crossing request, and encrypt the sub-network crossing request in the first trusted execution environment based on a first public key corresponding to a second trusted execution environment to obtain an encryption request;

an encryption request sending unit 702, configured to send the encryption request to the second subnet node, and receive an encryption response returned by the second subnet node, where the encryption response is obtained by the second subnet node by: reading the encryption request into a second trusted execution environment, decrypting the encryption request based on a first private key corresponding to the second trusted execution environment in the second trusted execution environment to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain the encryption response;

the encrypted response decryption unit 703 is configured to read the encrypted response into the first trusted execution environment, and decrypt the encrypted response in the first trusted execution environment based on a second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

Optionally, the first intelligent contract is run in the first trusted execution environment by the first subnet node by loading a first intelligent contract program in the first trusted execution environment, where the first intelligent contract program is obtained by the first subnet node decrypting a first intelligent contract program ciphertext read from outside the first trusted execution environment in the first trusted execution environment.

Optionally, the cross-subnet reply is generated by executing the cross-subnet request by a second smart contract running in a second trusted execution environment.

Optionally, the second intelligent contract is run in the second trusted execution environment by the second subnet node by loading a second intelligent contract program in the second trusted execution environment, where the second intelligent contract program is obtained by the second subnet node decrypting a second intelligent contract program ciphertext read from outside the second trusted execution environment in the second trusted execution environment.

Optionally, the cross-subnet request includes: the subnet nodes in the second blockchain subnet participate in the executed common transaction together, or the local transaction is executed only by the second subnet node independently.

Optionally, the method further includes:

and a cross-subnet transaction executing unit 704, configured to read the cross-subnet transaction ciphertext into the first trusted executing environment, decrypt the cross-subnet transaction ciphertext in the first trusted executing environment to obtain a cross-subnet transaction, and invoke the first intelligent contract to execute the cross-subnet transaction to generate the cross-subnet request.

Fig. 8 is a block diagram of another cross-subnet calling apparatus provided in the present specification according to an exemplary embodiment, which may be applied to the device shown in fig. 6 to implement the technical solution of the present specification; the device is applied to a second subnet node in a second blockchain subnet managed by a blockchain main network, the second subnet node maintains a second trusted execution environment, the blockchain main network also manages a first blockchain subnet, and a first subnet node in the first blockchain subnet maintains a first trusted execution environment; the device comprises:

an encryption request receiving unit 801, configured to receive an encryption request obtained by encrypting, by a first subnet node, a cross-subnet request in a first trusted execution environment based on a first public key corresponding to a second trusted execution environment, where the cross-subnet request is generated by running a first intelligent contract in the first trusted execution environment by the first subnet node;

an encrypted response obtaining unit 802, configured to read the encrypted request into a second trusted execution environment, decrypt the encrypted request in the second trusted execution environment based on a first private key corresponding to the second trusted execution environment to obtain the cross-subnet request, execute the cross-subnet request to generate a corresponding cross-subnet response, and encrypt the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain an encrypted response;

an encrypted response sending unit 803, configured to send the encrypted response to the first subnet node, so that the first subnet node reads the received encrypted response into the first trusted execution environment, and decrypts the encrypted response in the first trusted execution environment based on the second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical blocks. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is an integrated circuit whose Logic functions are determined by a user programming the Device. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, 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, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a server system. Of course, the present invention does not exclude that as future computer technology develops, the computer implementing the functionality of the above described embodiments may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device or a combination of any of these devices.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive approaches. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures. The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, article, or apparatus that comprises the recited elements is not excluded. For example, if the terms first, second, etc. are used to denote names, they do not denote any particular order.

For convenience of description, the above devices are described as being divided into various modules by functions, which are described separately. Of course, when implementing one or more of the present description, the functions of each module may be implemented in one or more software and/or hardware, or the modules implementing the same functions may be implemented by a combination of a plurality of sub-modules or sub-units, etc. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The present 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 flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may 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, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

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

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

As will be appreciated by one skilled in the art, one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, one or more embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

One or more embodiments of the specification may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. One or more embodiments of the present specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment. In the description of the specification, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the specification. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Moreover, various embodiments or examples and features of various embodiments or examples described in this specification can be combined and combined by one skilled in the art without being mutually inconsistent.

The above description is merely exemplary of one or more embodiments of the present disclosure and is not intended to limit the scope of one or more embodiments of the present disclosure. Various modifications and alterations to one or more embodiments described herein will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement or the like made within the spirit and principle of the present specification should be included in the scope of the claims.

Claims

1. A cross-subnet calling method is applied to a first subnet node in a first block chain subnet managed by a block chain master network, wherein the first subnet node maintains a first trusted execution environment, the block chain master network also manages a second block chain subnet, and a second subnet node in the second block chain subnet maintains a second trusted execution environment; the method comprises the following steps:

2. The method of claim 1, the first intelligent contract being run in the first trusted execution environment by the first subnet node by loading a first intelligent contract program in the first trusted execution environment, wherein the first intelligent contract program is decrypted in the first trusted execution environment by the first subnet node for first intelligent contract program cryptograms read in from outside the first trusted execution environment.

3. The method of claim 1, the cross-subnet reply generated by execution of the cross-subnet request by a second smart contract running in a second trusted execution environment.

4. The method of claim 3, the second intelligent contract being run in the second trusted execution environment by the second subnet node by loading a second intelligent contract program in the second trusted execution environment, wherein the second intelligent contract program is decrypted in the second trusted execution environment by the second subnet node a second intelligent contract program ciphertext read in from outside the second trusted execution environment.

5. The method of claim 1, the cross-subnet request comprising: the subnet nodes in the second blockchain subnet participate in the executed common transaction together, or the local transaction is executed only by the second subnet node independently.

6. The method of claim 1, the first subnet node and the second subnet node being deployed at the same or different node devices.

7. The method of claim 1, further comprising:

reading the cross-subnet transaction ciphertext into a first trusted execution environment, decrypting the cross-subnet transaction ciphertext in the first trusted execution environment to obtain a cross-subnet transaction, and calling a first intelligent contract to execute the cross-subnet transaction to generate the cross-subnet request.

8. A cross-subnet calling method is applied to a second subnet node in a second blockchain subnet managed by a blockchain master network, wherein the second subnet node maintains a second trusted execution environment, the blockchain master network also manages a first blockchain subnet, and the first subnet node in the first blockchain subnet maintains a first trusted execution environment; the method comprises the following steps:

9. A cross-subnet calling device is applied to a first subnet node in a first block chain subnet managed by a block chain master network, wherein the first subnet node maintains a first trusted execution environment, the block chain master network also manages a second block chain subnet, and a second subnet node in the second block chain subnet maintains a second trusted execution environment; the device comprises:

an encryption request sending unit, configured to send the encryption request to the second subnet node, and receive an encryption response returned by the second subnet node, where the encryption response is obtained by the second subnet node by: reading the encryption request into a second trusted execution environment, decrypting the encryption request based on a first private key corresponding to the second trusted execution environment in the second trusted execution environment to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting the cross-subnet response based on a second public key corresponding to the first trusted execution environment to obtain the encryption response;

10. A cross-subnet calling device is applied to a second subnet node in a second blockchain subnet managed by a blockchain main network, wherein the second subnet node maintains a second trusted execution environment, the blockchain main network also manages a first blockchain subnet, and the first subnet node in the first blockchain subnet maintains a first trusted execution environment; the device comprises:

and the encrypted response sending unit is used for sending the encrypted response to the first subnet node so as to enable the first subnet node to read the received encrypted response into the first trusted execution environment, and decrypting the encrypted response in the first trusted execution environment based on a second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

11. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

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

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