WO2024001022A1

WO2024001022A1 - Cross-subnet calling

Info

Publication number: WO2024001022A1
Application number: PCT/CN2022/135244
Authority: WO
Inventors: 黄祖城
Original assignee: 蚂蚁区块链科技(上海)有限公司
Priority date: 2022-06-29
Filing date: 2022-11-30
Publication date: 2024-01-04
Also published as: CN115134075A

Abstract

The present description provides a cross-subnet calling method and apparatus, an electronic device, and a storage medium. The method is applied to a first subnet node in a first blockchain subnet managed by a blockchain mainnet; the first subnet node maintains a first trusted execution environment, the blockchain mainnet 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: running a first smart contract in the first trusted execution environment to generate a cross-subnet request and encrypting same to obtain an encrypted request; sending the encrypted request to the second subnet node, and receiving an encrypted response returned by the second subnet node, the encrypted response being obtained by the second subnet node by means of the following approach: reading the encrypted request into the second trusted execution environment for decryption to obtain the cross-subnet request, executing the cross-subnet request to generate a corresponding cross-subnet response, and encrypting same to obtain the encrypted response; and reading the encrypted response into the first trusted execution environment for decryption to obtain the cross-subnet response.

Description

Calling across subnets

Technical field

The embodiments of this specification belong to the field of blockchain technology, and particularly relate to a cross-subnet calling method, device, electronic device and storage medium.

Background technique

Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm. In the blockchain system, data blocks are combined into a chained data structure in a chronological manner and are cryptographically guaranteed to be an untamperable and unforgeable distributed ledger. Due to the characteristics of blockchain, such as decentralization, non-tamperable information, and autonomy, blockchain has also received more and more attention and applications.

In some blockchain networks, some nodes sometimes have the need to implement small-scale transactions to prevent other nodes from obtaining these transactions and related data. This can be achieved by further establishing a blockchain subnet based on the blockchain main network. to fulfill. In a scenario where multiple blockchain subnets are established on the blockchain main network, there are requirements for cross-subnet calls between different blockchain subnets.

Contents of the invention

The purpose of the present invention is to provide a cross-subnet calling method, device, electronic device and storage medium.

According to the first aspect of one or more embodiments of this specification, a cross-subnet calling method is proposed, which is applied to the first subnet node in the first blockchain subnet managed by the blockchain main network. A subnet node maintains a first trusted execution environment, the blockchain mainnet also manages a second blockchain subnet, and the second subnet node in the second blockchain subnet maintains a second trusted execution environment environment; the method includes: running the first smart contract in the first trusted execution environment to generate a cross-subnet request, and in the first trusted execution environment based on the first public key pair corresponding to the second trusted execution environment. Encrypt the cross-subnet request to obtain an encryption request; send the encryption request to the second subnet node, and receive an encrypted response returned by the second subnet node. The encrypted response is obtained by the second subnet node in the following manner : Read the encrypted request into the second trusted execution environment, and decrypt 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. , execute the cross-subnet request to generate a corresponding cross-subnet response, and encrypt the cross-subnet response based on the second public key corresponding to the first trusted execution environment to obtain the encrypted response; encrypt the The response is read into the first trusted execution environment, and the encrypted response is decrypted 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.

According to the second aspect of one or more embodiments of this specification, a cross-subnet calling method is proposed, which is applied to the second subnet node in the second blockchain subnet managed by the blockchain main network. The second subnet node maintains a second trusted execution environment, the blockchain mainnet also manages a first blockchain subnet, and the first subnet node in the first blockchain subnet maintains a first trusted execution environment environment; the method includes: receiving an encryption request obtained by encrypting a 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 The cross-subnet request is generated by the first subnet node running the first smart contract in the first trusted execution environment; the encrypted request is read into the second trusted execution environment, and is executed in the second trusted execution environment based on the first smart contract. The first private key corresponding to the two trusted execution environments decrypts the encrypted request to obtain the cross-subnet request, executes the cross-subnet request to generate a corresponding cross-subnet response, and generates a corresponding cross-subnet response based on the first trusted execution environment The corresponding second public key encrypts the cross-subnet response to obtain an encrypted response; the encrypted response is sent to the first subnet node, so that the first subnet node reads the received encrypted response into the first subnet node. A trusted execution environment, and in the first trusted execution environment, the encrypted response is decrypted based on the second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.

According to the third aspect of one or more embodiments of this specification, a cross-subnet calling device is proposed, which is applied to the first subnet node in the first blockchain subnet managed by the blockchain main network. A subnet node maintains a first trusted execution environment, the blockchain mainnet also manages a second blockchain subnet, and the second subnet node in the second blockchain subnet maintains a second trusted execution environment environment; the device includes: an encrypted request acquisition unit, configured to run the first smart contract in the first trusted execution environment to generate a cross-subnet request, corresponding in the first trusted execution environment based on the second trusted execution environment The first public key encrypts the cross-subnet request to obtain an encryption request; the encryption request sending unit is used to send the encryption request to the second subnet node and receive the encrypted response returned by the second subnet node, The encrypted response is obtained by the second subnet node in the following manner: reading the encrypted request into the second trusted execution environment, and in the second trusted execution environment based on the first private key corresponding to the second trusted execution environment The encrypted request is decrypted to obtain the cross-subnet request, the cross-subnet request is executed to generate a corresponding cross-subnet response, and the cross-subnet response is generated based on the second public key corresponding to the first trusted execution environment. The network response is encrypted to obtain the encrypted response; the encrypted response decryption unit is used to read the encrypted response into the first trusted execution environment, and in the first trusted execution environment based on the second trusted execution environment corresponding to the first trusted execution environment The private key decrypts the encrypted response to obtain the cross-subnet response.

According to the fourth aspect of one or more embodiments of this specification, a cross-subnet calling device is proposed, which is applied to the second subnet node in the second blockchain subnet managed by the blockchain main network. The second subnet node maintains a second trusted execution environment, the blockchain mainnet also manages a first blockchain subnet, and the first subnet node in the first blockchain subnet maintains a first trusted execution environment Environment; the device includes: an encryption request receiving unit, configured to receive a cross-subnet request obtained by the first subnet node encrypting a cross-subnet request based on the first public key corresponding to the second trusted execution environment in the first trusted execution environment. Encrypted request, wherein the cross-subnet request is generated by the first subnet node running the first smart contract in the first trusted execution environment; the encrypted response acquisition unit is used to read the encrypted request into the second trustworthy execution environment Trust execution environment, in the second trusted execution environment, decrypt the encrypted request based on the first private key corresponding to the second trusted execution environment to obtain the cross-subnet request, execute the cross-subnet request to generate the corresponding a cross-subnet response, and encrypts the cross-subnet response based on the second public key corresponding to the first trusted execution environment to obtain an encrypted response; an encrypted response sending unit configured to send the encrypted response to the first subnet network node, so that the first subnet node reads the received encrypted response into the first trusted execution environment, and in the first trusted execution environment based on the second private key pair corresponding to the first trusted execution environment The encrypted response is decrypted to obtain the cross-subnet response.

According to a fifth aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor; a memory for storing executable instructions by the processor; wherein the processor executes the executable instructions To implement the method described in any one of the first aspect and the second aspect.

According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is proposed, on which computer instructions are stored, and when the instructions are executed by a processor, any one of the first and second aspects is implemented. The steps of the method described in the item.

In the embodiment of this specification, the first subnet node and the second subnet node are in different blockchain subnets respectively. When a cross-subnet call is made between the first subnet node and the second subnet node, By maintaining corresponding trusted execution environments on the first subnet node and the second subnet node respectively, the security of the first subnet node and the second subnet node during node operation can be ensured, and each other can pass each other through The public key corresponding to the trusted execution environment encrypts the cross-subnet request or cross-subnet response to ensure the security of the cross-subnet communication process, the security of the node operation process and the security of the cross-subnet communication process. Cooperate with each other to ultimately achieve system-level security for the entire cross-subnet calling process.

Description of drawings

In order to explain the technical solutions of the embodiments of this specification more clearly, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some of the embodiments recorded in this specification. , for those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative labor.

Figure 1 is a schematic diagram of establishing a blockchain subnet based on the blockchain main network according to an exemplary embodiment.

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

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

Figure 4 is an application scenario diagram of another cross-subnet calling method provided by an exemplary embodiment.

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

Figure 6 is a schematic structural diagram of a device provided by an exemplary embodiment.

Figure 7 is a block diagram of a cross-subnet calling device provided in an exemplary embodiment.

Figure 8 is a block diagram of another cross-subnet calling device provided by an exemplary embodiment.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of this specification. Obviously, the described The embodiments are only some of the embodiments of this specification, but not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of this specification.

Due to the decentralized nature of the blockchain network, all blockchain nodes in the blockchain network maintain the same block data, which cannot meet the special needs of some nodes. Taking the alliance chain as an example, all alliance members (i.e., node members within the alliance) can form a blockchain network. All alliance members have corresponding blockchain nodes in the blockchain network and can pass through the corresponding zones. Blockchain nodes obtain all transactions and related data that occur on the blockchain network. However, in some cases, there may be some alliance members who want to complete some transactions with confidentiality requirements. These alliance members hope that these transactions can be stored on the blockchain or take advantage of other advantages of blockchain technology, and can avoid other Alliance members view these transactions and related data. Although these alliance members can additionally form a new blockchain network, which is similar to the above-mentioned blockchain network containing all alliance members, building a new blockchain network from scratch requires a large amount of resources, and regardless of The establishment process of the blockchain network or the configuration process after it is built are very time-consuming. The demands among alliance members are often temporary or time-sensitive, so that the newly built blockchain network will soon lose the meaning of existence due to the disappearance of demand, thus further increasing the chain construction cost of the above-mentioned blockchain network. . The needs among alliance members often change, and the alliance members corresponding to each demand are often different. Therefore, whenever alliance members change, a new blockchain network may need to be formed, resulting in a loss of resources and time. A lot of waste.

To this end, the established blockchain network can be used as the blockchain main network, and a blockchain subnet can be established based on the blockchain main network. Then, in a consortium chain scenario such as the above, consortium members can establish the required blockchain subnet based on their own needs based on their own needs after already participating in the blockchain mainnet. Since the blockchain subnet is established on the basis of the blockchain main network, the construction process of the blockchain subnet consumes more resources and takes more time than establishing a completely independent blockchain network. are greatly reduced and the flexibility is extremely high.

The process of quickly establishing a blockchain subnet based on the blockchain main network is as follows: Each blockchain node in the blockchain main network obtains the transaction to establish the blockchain subnet respectively, and the transaction includes the configuration information of the blockchain subnet. , the configuration information includes the identity information of the node members participating in the establishment of the blockchain subnet, and each blockchain node in the blockchain main network executes the transaction respectively to reveal the configuration information. When the When the configuration information contains the identity information of the node member corresponding to the first blockchain node, the node device deploying the first blockchain node starts the third node belonging to the blockchain subnet based on the genesis block containing the configuration information. Two blockchain nodes.

Taking the example shown in Figure 1, the blockchain main network is subnet0, and the blockchain nodes included in subnet0 are nodeA, nodeB, nodeC, nodeD, nodeE, etc. Assume that nodeA, nodeB, nodeC and nodeD want to form a blockchain subnet: If nodeA is the administrator and only allows the administrator to initiate transactions to form a blockchain subnet, then nodeA can initiate the above transaction to form a blockchain subnet to subnet0; If nodeE is the administrator and only allows the administrator to initiate transactions to establish a blockchain subnet, then nodeA ~ nodeD need to request nodeE, so that nodeE initiates the above-mentioned transaction to establish a blockchain subnet to subnet0; if nodeE is an administrator but allows If an ordinary user initiates a transaction to establish a blockchain subnet, then nodeA ~ nodeE can initiate the above-mentioned transaction to establish a blockchain subnet to subnet0. Of course, whether an administrator or an ordinary user, the blockchain node that initiates the transaction to establish the blockchain subnet does not necessarily participate in the formed blockchain subnet. For example, although the blockchain subnet is ultimately formed by nodeA, nodeB, nodeC, and nodeD network, but nodeE can initiate the above-mentioned transaction of forming a blockchain subnet to subnet0, and it is not necessarily nodeA~nodeD that initiates the transaction of forming a blockchain subnet.

When building a blockchain subnet based on the blockchain mainnet, it is easy to understand that there will be a logical hierarchical relationship between the blockchain subnet and the blockchain mainnet. For example, when building a blockchain subnet subnet1 on subnet0 shown in Figure 1, it can be considered that subnet0 is on the first layer and subnet1 is on the second layer. In one case, the blockchain main network in this specification can be the underlying blockchain network, that is, the blockchain main network is not a blockchain subnet established on the basis of other blockchain networks, such as the one in Figure 1 subnet0 can be considered as the blockchain mainnet belonging to the underlying blockchain network type. In another case, the blockchain mainnet in this specification can also be a subnet of other blockchain networks. For example, another blockchain subnet can be further established based on subnet1 in Figure 1. In this case, it can be considered subnet1 is the blockchain mainnet corresponding to the blockchain subnet, and this does not affect that subnet1 also belongs to the blockchain subnet created on subnet0. It can be seen that the blockchain main network and the blockchain subnet are actually relative concepts. The same blockchain network can be the blockchain main network in some cases and the blockchain subnet in other cases.

After the above-mentioned transactions that form the blockchain subnet are sent to the blockchain main network, they are consensused by the consensus nodes in the blockchain main network. After passing the consensus, the transactions are executed by each main network node to complete the block. The establishment of chain subnet. The consensus process depends on the consensus mechanism used, and this instruction does not limit this.

By including configuration information in the above-mentioned transaction for forming a blockchain subnet, the configuration information can be used to configure the formed blockchain subnet so that the formed blockchain subnet meets the networking requirements. For example, by including the identity information of node members in the configuration information, you can specify which blockchain nodes are included in the formed blockchain subnet.

The identity information of node members may include the public key of the node, or other information that can characterize the identity of the node, such as node ID. This specification does not limit this. Taking the public key as an example, each blockchain node has one or more corresponding sets of public and private key pairs. The blockchain node holds the private key and the public key is made public and uniquely corresponds to the private key. Therefore, it can be The public key represents the identity of the corresponding blockchain node. Therefore, for blockchain nodes that wish to serve as node members of the blockchain subnet, the public keys of these blockchain nodes can be added to the above-mentioned transaction for forming the blockchain subnet as the identity information of the above-mentioned node members. The above public and private key pairs can be used in the signature verification process. For example, when using a signed consensus algorithm, for example, the nodeA1 mentioned above in subnet1 signs the message using its own private key, and then broadcasts the signed message in subnet1, while nodeB1, nodeC1 and nodeD1 can use the public key of nodeA1. Perform signature verification on the received message to confirm that the message received does come from nodeA1 and has not been tampered with.

The first main network node may be a blockchain node on the blockchain main network that belongs to the node member indicated by the configuration information. When building a blockchain subnet, the first mainnet node does not directly participate in forming the blockchain subnet and become its node member. Instead, the node device used to deploy the first mainnet node needs to generate the first subnet node. , and the first subnet node becomes a node member in the blockchain subnet. The first mainnet node and the first subnet node correspond to the same blockchain member. For example, in the alliance chain scenario, they correspond to the same alliance chain member, but the first mainnet node belongs to the blockchain mainnet and the first subnet. The node belongs to the blockchain subnet, so that the blockchain members can participate in the transactions of the blockchain main network and the blockchain subnet respectively; and, since the blockchain main network and the blockchain subnet are two independent The blockchain network allows the blocks generated by the first main network node and the blocks generated by the first sub-network node to be stored in different storage on the node device (the storage used can be a database, for example), realizing the first The storage used by the main network node and the first sub-network node is isolated from each other. Therefore, the data generated by the blockchain sub-network will only be synchronized among the node members of the blockchain sub-network, so that only those participating in the blockchain main network will be synchronized. The blockchain members of the network cannot obtain the data generated on the blockchain subnet, which realizes the data isolation between the blockchain main network and the blockchain subnet, and satisfies the needs of some blockchain members (i.e., the districts participating in the blockchain subnet). Transaction needs between blockchain members).

It can be seen that the first main network node and the first sub network node are logically divided blockchain nodes. From the perspective of physical equipment, it is equivalent to the above deployment of the first main network node and the first sub network node. The node equipment participates in both the blockchain main network and the blockchain subnet. Since the blockchain main network and the blockchain sub-network are independent of each other, the identity systems of the two blockchain networks are also independent of each other. Therefore, even the first main network node and the first sub-network node can use the exact same public name. key, the two should still be considered different blockchain nodes. For example, in Figure 1, nodeA in subnet0 is equivalent to the first main network node, and the node device deploying nodeA generates nodeA1 belonging to subnet1, which is equivalent to the first subnet node. It can be seen that since the identity systems are independent of each other, even if the public key used by the first subnet node is different from that of the first mainnet node, it will not affect the implementation of the solution in this specification.

Of course, the node members of the blockchain subnet are not necessarily only some of the node members of the blockchain mainnet. In some cases, the node members of the blockchain subnet can be completely consistent with the node members of the blockchain main network. At this time, all blockchain members can obtain the data on the blockchain main network and the blockchain subnet, but The data generated by the blockchain main network and the blockchain subnet can still be isolated from each other. For example, one type of business can be implemented on the blockchain main network and another type of business can be implemented on the blockchain subnet, so that the two types of Business data generated by businesses are isolated from each other.

In addition to the identity information of the node members mentioned above, the configuration information may also include at least one of the following: the network identifier of the blockchain subnet, the identity information of the administrator of the blockchain subnet, the identity information for the blockchain platform This manual does not limit the attribute configuration of the code. The network identifier is used to uniquely characterize the blockchain subnet, so the network identifier of the blockchain subnet should be distinguished from the blockchain main network and other blockchain subnets formed on the blockchain main network. The identity information of the administrator of the blockchain subnet, for example, can be the public key of the node member who is the administrator; among them, the administrators of the blockchain main network and the blockchain subnet can be the same or different.

One of the advantages of building a blockchain subnet through the blockchain mainnet is that since the first mainnet node has been deployed on the node device that generates the first subnet node, the area used by the first mainnet node can be The blockchain platform code is reused on the first subnet node, which eliminates the need for repeated deployment of the blockchain platform code and greatly improves the efficiency of building the blockchain subnet. Then, if the configuration information does not contain the attribute configuration for the blockchain platform code, the first subnet node can reuse the attribute configuration adopted on the first main network node; if the configuration information contains the attribute configuration for the blockchain platform code, Attribute configuration, the first subnet node can adopt this attribute configuration, so that the attribute configuration adopted by the first subnet node is not limited to the attribute configuration of the first main network node and has nothing to do with the first main network node. The attribute configuration of the blockchain platform code can include at least one of the following: code version number, whether consensus is required, consensus algorithm type, block size, etc. This specification does not limit this.

Transactions that build a blockchain subnet include transactions that call contracts. The transaction can specify the address of the called smart contract, the method called and the parameters passed in. For example, the contract called can be the aforementioned creation contract or system contract, the method called can be a method of establishing a blockchain subnet, and the parameters passed in can include the above configuration information. In one embodiment, the transaction may include the following information:

from：Administrator

to：Subnet

method:AddSubnet(string)

string: genesis

Among them, the from field is the information of the initiator of the transaction, for example, Administrator indicates that the initiator is the administrator; the to field is the address of the called smart contract, for example, the smart contract can be a Subnet contract, then the to field is specifically the Subnet The address of the contract; the method field is the method called. For example, the method used to build a blockchain subnet in the Subnet contract can be AddSubnet(string), and string is the parameter in the AddSubnet() method. In the above example, genesis is used to represent this The value of the parameter, the genesis is specifically the aforementioned configuration information.

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

After nodes in the blockchain network execute transactions that call smart contracts, they will generate corresponding receipts to record information related to the execution of the smart contract. In this way, relevant information about the contract execution results can be obtained by querying the receipt of the transaction. Contract execution results can be represented as events in receipts. The message mechanism can realize message delivery through events in receipts to trigger blockchain nodes to perform corresponding processing. The structure of the event can be, for example:

Event:

[topic][data]

...

In the above example, the number of events may be one or more; each event includes fields such as topic and data. The blockchain node can listen to the topic of the event, and then perform preset processing when listening to the predefined topic, or read the relevant content from the data field of the corresponding event, and can execute the preset based on the read content. deal with.

In the above event mechanism, it is equivalent to the existence of a client with a monitoring function at the listening party (such as a user with monitoring needs). For example, the client runs an SDK for implementing the monitoring function, etc., and the client monitors the area. Events generated by the blockchain node are monitored, and the blockchain node only needs to generate receipts normally. In addition to the above event mechanism, transaction information can also be revealed through other methods. For example, the listening code can be embedded in the blockchain platform code running on the blockchain node, so that the listening code can monitor the transaction content of the blockchain transaction, the contract status of the smart contract, the receipt generated by the contract, etc. or multiple types of data, and sends the monitored data to the predefined listening party. Since the listening code is deployed in the blockchain platform code rather than on the client of the listening party, this implementation method based on listening code is relatively more proactive compared to the event mechanism. Among them, the above-mentioned monitoring code can be added to the blockchain platform code by the developers of the blockchain platform during the development process, or can be embedded by the monitoring party based on its own needs. This manual does not limit this.

It can be seen that the execution result of the above Subnet contract may include the configuration information, and the execution result may be in the receipt mentioned above. The receipt may include events related to the execution of the AddSubnet() method, that is, networking events. The topic of the networking event can contain a predefined networking event identifier to distinguish it from other events. For example, in an event related to the execution of the AddSubnet() method, the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods. Then, by monitoring the topics contained in each event in the generated receipt, nodeA~nodeE can determine that they have listened to the event related to the execution of the AddSubnet() method, that is, the networking event, when they listen to the topic containing the keyword subnet. For example, the events in the receipt are as follows:

Event:

[topic:other][data]

[topic:subnet][data]

...

Then, when nodeA~nodeE listens to the first event, since the content of the topic contained is other, it is determined that the event has nothing to do with the AddSubnet() method; and, when nodeA~nodeE listens to the second event, because the content of the topic contained The content of the topic is subnet. It is determined that the event is related to the AddSubnet() method, and then the data field corresponding to the event is read. The data field contains the above configuration information. Taking the configuration information including the public keys of node members of the blockchain subnet as an example, the content of the data field may include:

{subnet1;

nodeA's public key, nodeA's IP, nodeA's port number...;

nodeB’s public key, nodeB’s IP, nodeB’s port number…;

nodeC’s public key, nodeC’s IP, nodeC’s port number…;

nodeD’s public key, nodeD’s IP, nodeD’s port number…;

}

Among them, subnet1 is the network identifier of the blockchain subnet you want to create. Each blockchain node in the blockchain main network can record the network identifiers of all blockchain subnets that have been created on the blockchain main network, or other information related to these blockchain subnets. This information can, for example, be maintained in In the above-mentioned Subnet contract, it may specifically correspond to the value of one or more contract states contained in the Subnet contract. Then, nodeA~nodeE can determine whether the above subnet1 already exists based on the recorded network identifiers of all created blockchain subnets; if it does not exist, it means that subnet1 is the new blockchain subnet that needs to be created currently. If it exists, it means that subnet1 already exists.

In addition to using the network identifier of the new blockchain subnet you wish to create, you can also use a predefined new network identifier, which indicates that the corresponding networking event is used to form a new blockchain subnet. For example, you can replace the above subnet1 with newsubnet, which is a predefined new network identifier. When nodeA ~ nodeE recognize that the data field contains newsubnet, they can determine that the event containing the newsubnet is a networking event, and a new one needs to be created. Blockchain subnet.

In addition to the network identifier subnet1, the above data field also contains the identity information of each node member and other contents. The node device deploying the first main network node may monitor the generated receipt, and when the networking event is monitored and the content of the networking event indicates that the first main network node belongs to the node member, the node device deploying the first main network node may monitor the generated receipt. The node device of a main network node obtains the configuration information or genesis block contained in the networking event. Alternatively, the first blockchain node can monitor the generated receipt, and trigger the deployment of the first blockchain node when the networking event is monitored and the content of the networking event indicates that the first blockchain node belongs to the node member. The node device of a blockchain node obtains the configuration information or the genesis block included in the networking event.

As mentioned before, node devices can listen directly for receipts. Assume that nodeA ~ nodeE are deployed on node devices 1 ~ 5 respectively. Node devices 1 ~ 5 can monitor the receipts generated by nodeA ~ nodeE respectively. Then when it is detected that subnet1 is a newly established blockchain subnet, node device 1 ~5 will further identify the identity information of the node members contained in the data field to determine its own processing method. Taking nodeA and node device 1 as an example: If node device 1 finds that the data field contains nodeA's public key, IP address, port number and other identity information, then node device 1 obtains the configuration information from the data field based on the above message mechanism. , generate a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and then nodeA1 will load the generated genesis block, thus becoming a subnet node of subnet1; similarly, node device 2 can generate nodeB1, node Device 3 can generate nodeC1, and node device 4 can generate nodeD1. And, node device 5 will find that the identity information contained in the data field does not match itself, then the node device 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate a blockchain node in subnet1.

As mentioned before, blockchain nodes in the blockchain main network can monitor receipts and trigger node devices to perform relevant processing based on the monitoring results. For example, when nodeA~nodeE determines that subnet1 is a newly established blockchain subnet, they will further identify the identity information of the node members contained in the data field to determine their own processing method. For example, nodeA ~ nodeD will find that the data field contains their own public key, IP address, port number and other identity information. Assume that nodeA ~ nodeD are deployed on node devices 1 ~ 4 respectively. Taking nodeA and node device 1 as an example: nodeA will Trigger node device 1 so that node device 1 obtains configuration information from the data field based on the above message mechanism and generates a genesis block containing the configuration information, and node device 1 will deploy nodeA1 locally, and nodeA1 loads the generated genesis block. Thus, it becomes a subnet node in subnet1; similarly, nodeB will trigger node device 2 to generate nodeB1, nodeC will trigger node device 3 to generate nodeC1, and nodeD will trigger node device 4 to generate nodeD1. Also, nodeE will find that the identity information contained in the data field does not match itself. Assuming that nodeE is deployed on node device 5, then node device 5 will not generate a genesis block based on the configuration information in the data field, nor will it generate subnet1. nodes in .

As mentioned above, the first main network node and the first subnet node do not necessarily use the same identity information. Therefore, in the above embodiment, the data field may contain identity information generated in advance for nodeA1 to nodeD1, and is different from the identity information of nodeA to nodeD. Still taking nodeA and node device 1 as an example: If node device 1 finds the identity information of nodeA1 in the data field, it can generate a genesis block, deploy nodeA1, and load the genesis block by nodeA1; or, if nodeA finds the identity information of nodeA1 in the data field, If the identity information of nodeA1 is found, then nodeA will trigger node device 1 to generate a genesis block, deploy nodeA1, and nodeA1 will load the genesis block. Other blockchain nodes or node devices are handled in a similar manner and will not be described here.

In addition to configuration information, the execution results of the contract can include the genesis block. In other words, in addition to including configuration information in the data field, you can also directly generate a genesis block containing configuration information during the execution of the contract call, thereby including the genesis block in the data field. Then for the above nodeA ~ nodeD In other words, the corresponding node devices 1 to 4 can directly obtain the genesis block from the data field through the message mechanism without having to generate it themselves, which can improve the deployment efficiency of nodeA1 to nodeD1.

The node device implements the deployment of a blockchain node on the node device by creating an instance running the blockchain platform code in the process. For the first main network node, the node device creates a first instance in the above process, and the first instance runs the blockchain platform code. Similarly, for the first subnet node, the node device creates a second instance that is different from the first instance in the above process, and the second instance runs the blockchain platform code. For example, the node device can first create a first instance in the process to form the first blockchain node in the blockchain main network; and when the node member corresponding to the node device wants to participate in forming the blockchain subnet, they can A second instance is created in the above process, which is different from the above first instance, and the second instance forms a second blockchain node in the blockchain subnet. When the first instance and the second instance are in the same process, since no cross-process interaction is involved, the difficulty of deploying the first subnet node can be reduced and the deployment efficiency can be improved; of course, the second instance may also be in separate nodes from the first instance. In different processes on the device, this specification does not limit this; for example, the node device can create the first instance in the first process to form the first blockchain node in the blockchain main network; and when the node When the node members corresponding to the device wish to participate in building a blockchain subnet, they can start a second process that is different from the first process, and create a second instance in the second process. The second instance is different from the above-mentioned first instance. The second instance then forms a second blockchain node in the blockchain subnet. In fact, each blockchain node deployed on any node device involved in the embodiments of this specification is a different blockchain instance running on any node device. Each blockchain node deployed on any node device The blocks generated by the nodes are stored in different storages (such as databases) on any node device, and the storage used by each blockchain node deployed on any node device is isolated from each other.

Through the above method, a blockchain subnet can be created on the blockchain mainnet. Taking Figure 1 as an example, subnet0 originally contains nodeA~nodeE, and subnet1 can be formed based on subnet0. This subnet1 contains nodeA1~nodeD1, and nodeA and nodeA1, nodeB and nodeB1, nodeC and nodeC1, nodeD and nodeD1 are respectively deployed in on the same node device. Similarly, subnet2 or more blockchain subnets can be established on subnet0, where subnet2 includes nodeA2, nodeB2, nodeC2 and nodeE2, and nodeA is connected with nodeA1, nodeA2, nodeB is connected with nodeB1, nodeB2, nodeC, nodeC1 and nodeC2, nodeD and nodeD1, nodeE and nodeE2 are deployed on the same node device respectively. In addition, subnet1, subnet2, etc. can be used as new blockchain mainnets, and further build blockchain subnets on this basis. The process is similar to the establishment of subnet1 or subnet2, and will not be described again here. It can be seen that the above-mentioned method of initiating transactions on the blockchain main network to select node members to create a blockchain subnet can enable the subnet nodes of the newly created blockchain subnet to be deployed where the main network nodes of the blockchain main network are located. On the node device, that is, from the perspective of the node device, the node device where the subnet node of the blockchain subnet is located belongs to a subset of the node device where the main network node is located. In other words, the subnet node where the blockchain subnet is deployed belongs to the subset of node devices where the main network node is located. The main network nodes in the blockchain main network are deployed on the node equipment.

In addition to the above-mentioned method of initiating transactions on the blockchain main network and selecting node members to create a blockchain subnet, blockchain subnets can also be created through other means and made subject to the management of the blockchain main network. For example, a blockchain subnet can be established on the blockchain main network through registration (hereinafter referred to as the registration networking method), and the existing blockchain network can be directly registered to the blockchain main network, so that the newly registered blockchain network can Under the management of the blockchain main network, the newly registered blockchain network becomes a blockchain subnet of the blockchain main network. Through the registration network method, the subnet information of the blockchain subnet to be established is directly registered to the blockchain main network, so that the blockchain main network obtains the relevant information of the blockchain subnet to be established (by receiving and executing the area to be established) Transactions issued by the blockchain network to associate and store identity information with the subnet identifier assigned to the blockchain network to be established), such as the subnet identifier and operating status of the blockchain subnet to be established, where The public key and plug-in configuration information of each node member, the IP address and port information of each node device, etc. This information will be written into the contract status of the system contract corresponding to the blockchain main network. From this, the blockchain main network will Obtaining the management rights of the blockchain subnet to be formed and completing the registration means that the blockchain subnet is completed. Since the registration networking method does not require the designation of node members on the blockchain main network through transactions to form a blockchain subnet, the subnet nodes in the blockchain subnet established through the registration networking method can be compared with those deployed on the blockchain main network. The node equipment of each node in the network is completely or partially different. For example, in Figure 1, subnet0 creates a subnet4 in the registration networking mode (not shown in Figure 1). It is assumed that the main network nodes nodeA~nodeE included in subnet0 itself are deployed separately. on node devices 1 to 5, then the subnet nodes corresponding to subnet4 can be deployed on any other node devices except node devices 1 to 5, or one or more subnet nodes in subnet4 are deployed on node devices 1 to 5 respectively. Any node device within 5 (but it is still necessary to ensure that only one subnet node in subnet4 is deployed on a node device), and other subnet nodes in subnet4 are deployed on any other node device except node devices 1 to 5 , of course, the subnet nodes in subnet4 can also be deployed in node devices 1 to 5.

The cross-subnet calling method involved in this manual will be described in detail below with reference to Figure 2. Figure 2 is a flow chart of a cross-subnet calling method provided by an exemplary embodiment. The method is applied to a first subnet node in a first blockchain subnet managed by a blockchain mainnet, the first subnet node maintains a first trusted execution environment, and the blockchain mainnet also manages There is a second blockchain subnet, and the second subnet node in the second blockchain subnet maintains a second trusted execution environment; the method includes:

S202: Run the first smart contract in the first trusted execution environment to generate a cross-subnet request, and pair the cross-subnet request in the first trusted execution environment based on the first public key corresponding to the second trusted execution environment. Perform encryption to get the encrypted request.

In the embodiment of this specification, the first blockchain subnet and the second blockchain subnet are both created on the basis of the blockchain main network according to the aforementioned method of creating a blockchain subnet, where any blockchain subnet The network is managed by the blockchain main network, which can be expressed as follows: the blockchain main network can realize the start and stop of nodes and network structure of each blockchain subnet by calling the subnet management contract deployed by the blockchain main network. Adjustment and other management functions.

The first subnet node maintains a first trusted execution environment, which can place computing tasks such as transaction execution, consensus process, and contract operation during the node operation into the first trusted execution environment for execution. In this process , the first subnet node will read the ciphertext data outside the first trusted execution environment into the first trusted execution environment and decrypt it into plaintext data before performing operations. Therefore, the first subnet node can use the first trusted execution environment The confidentiality of the environment is used to determine the security of the first subnet node at the node operation level. Similarly, the second subnet node also maintains a second trusted execution environment, which can also use the second trusted execution environment in the above manner to achieve the security of the second subnet node at the node operation level.

In the embodiment of this specification, any subnet node in the first blockchain subnet or the second blockchain subnet can be deployed with a corresponding trusted execution environment, and achieve security at the operating level of each node in the above manner. , in this scenario, the first blockchain subnet and the second blockchain subnet are called TEE (Trusted Execution Environment, Trusted Execution Environment) chain.

When the first subnet node runs the first smart contract in the first trusted execution environment, the first smart contract may generate cross-subnet call requirements for other blockchain subnets, such as generating a link pointing to the second blockchain subnet. The cross-subnet request of the second subnet node requires that the cross-subnet request be transmitted to the second subnet node and executed in response, and at the same time, the cross-subnet request generated by the second subnet node executing the cross-subnet request is received. response. However, in order to ensure the security of cross-subnet requests and cross-subnet responses during transmission outside the trusted execution environment (cross-subnet communication), it is necessary to encrypt them in the trusted execution environment before proceeding. Communication across subnets. Therefore, the first subnet node will not directly send the cross-subnet request generated by the first smart contract running in the first trusted execution environment to the second subnet node, but first in the first trusted execution environment The cross-subnet request is encrypted based on the first public key corresponding to the second trusted execution environment to obtain an encrypted request, and then the encrypted request is sent to the second subnet node. In order to ensure that the encrypted request can be correctly routed to the second subnet node, specific fields in the original cross-subnet request will be retained during the encryption process, such as the identity information of the second subnet node (IP address, node public key or other identification) identification information of the second blockchain subnet, etc.

In this embodiment of the present description, the first trusted execution environment maintains a corresponding public and private key pair (the second public key and the second private key) to implement the encryption and decryption process of internal and external data in the first trusted execution environment, wherein: The second private key is held exclusively by the first trusted execution environment, and the second public key is made public. In the same way, the second trusted execution environment also maintains a corresponding public and private key pair (the first public key and the first private key) to implement the encryption and decryption process of internal and external data in the second trusted execution environment, where the first private key It is held exclusively by the second trusted execution environment, and the first public key is made public.

Therefore, when 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 an encrypted request, the encrypted request can theoretically only be obtained by uniquely holding the third A private key is decrypted in the second trusted execution environment maintained by the second subnet node, so that even if the encrypted request is captured by a third party during transmission outside the trusted execution environment, the third party will be decrypted due to the lack of the first private key. The cross-subnet request cannot be decrypted and restored to the plaintext state without the key, thereby ensuring the security of the cross-subnet communication process. This encrypted request is a private transaction because it has the nature and confidentiality of a blockchain transaction. .

In the embodiment of this specification, the first smart contract is run by the first subnet node in the first trusted execution environment by loading the first smart contract program in the first trusted execution environment, where the first smart contract program The first subnet node decrypts the first smart contract program ciphertext read from outside the first trusted execution environment in the first trusted execution environment. The first smart contract runs in the first trusted execution environment, which is actually the result of the first subnet node loading the first smart contract program in the first trusted execution environment. Since the first trusted execution environment is essentially a period of In a physically isolated execution environment, the programs running in it are all loaded in isolated memory. Therefore, persistent storage is required for programs that do not need to run in the first trusted execution environment temporarily. In order to ensure information security, any program running in the first trusted execution environment follows the principle of "decryption and loading inside the trusted execution environment, and optional encrypted storage outside the execution environment". Therefore, the essence of the first smart contract program The above is 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 program ciphertext is obtained by the first smart contract program through the first trusted execution environment. The second public key is encrypted and stored outside the first trusted execution environment. At the same time, it can be decrypted into the first smart contract program through the second private key inside the first trusted execution environment. Similar to the first smart contract, the second public key is stored in the trusted execution environment. Smart contracts that are executed in plain text within the execution environment but encrypted and stored outside the trusted execution environment are called privacy contracts.

S204: Send the encryption request to the second subnet node, and receive the encrypted response returned by the second subnet node. The encrypted response is obtained by the second subnet node in the following manner: reading the encryption request into the second subnet node. Two trusted execution environments. In the second trusted execution environment, the encrypted request is decrypted based on the first private key corresponding to the second trusted execution environment to obtain the cross-subnet request, and the cross-subnet request is executed to Generate a corresponding cross-subnet response, and encrypt the cross-subnet response based on the second public key corresponding to the first trusted execution environment to obtain the encrypted response.

After the first subnet node encrypts the cross-subnet request in the first trusted execution environment to obtain the encrypted request, it can send the encrypted request to the second subnet node through cross-subnet communication.

Cross-subnet communication between subnet nodes in different blockchain subnets is mainly achieved through pre-established network connection links between mainnet nodes deployed on their respective node devices. Taking Figure 1 as an example, the node device 3 where the first subnet node nodeC1 in the first blockchain subnet subnet1 is located is also deployed with the mainnet node nodeC in the blockchain mainnet subnet0, and the second blockchain subnet The main network node nodeE in subnet0 is also deployed on the node device 5 where the second subnet node nodeE2 in the network subnet2 is located. Assume that nodeC1 wants to send an encryption request to nodeE2. Although there is no direct network connection link between subnet1 and subnet2 (between nodeC and nodeE), due to the difference between nodeC deployed on node device 3 and nodeE deployed on node device 5, The network connection link implemented when forming subnet0 has been established in advance, and the network connection link allows node device 3 and node device 5 to communicate with each other. Therefore, nodeC1 can pass the network connection link established between nodeC and nodeE. path, thereby sending the encrypted request from node device 3 to node device 5, and finally routed by node device 5 to its locally deployed nodeE2. In one embodiment, the network connection link implemented when forming subnet0 is the consensus link established between the mainnet nodes in subnet0 for consensus on transactions and/or the synchronization for synchronization of blocks. link.

In the embodiment of this specification, the main network node and the subnet node on the same node device share the blockchain communication plug-in running on the node device, such as P2P (Peer to Peer, peer-to-peer network communication) plug-in, and when the above-mentioned subnet0 is formed The network connection link implemented is specifically established by nodeC and nodeE using the P2P plug-in on node device 3 and node device 5 respectively. Since the P2P plug-in on the node device can be shared by various blockchain nodes on the node device, Therefore, nodeC1 in subnet1 can call the P2P plug-in running locally on node device 3, and use the P2P plug-in-based network connection between node device 3 and node device 5 implemented when forming subnet0 to establish a connection with nodeE2 running on node device 5. The network connection between P2P plug-ins sends the encrypted request to the node device 5, thereby further realizing network communication with nodeE2. Therefore, there is no need to establish a new network connection link between the first blockchain subnet and the second blockchain subnet. Instead, the first blockchain subnet is realized through the pre-established network connection link of the underlying blockchain main network. Cross-subnet communication between the first subnet node in the blockchain subnet and the second subnet node in the second blockchain subnet.

After the second subnet node receives the encrypted response, the second subnet node will read the encrypted response into the second trusted execution environment it maintains, and execute the encrypted response in the second trusted execution environment based on the second trusted execution environment. The first private key corresponding to the environment decrypts the encrypted request and obtains 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, calling the second server running in the second trusted execution environment. The smart contract executes the cross-subnet request to generate a cross-subnet response, that is, the cross-subnet response is generated by the second smart contract running in the second trusted execution environment executing the cross-subnet request. When the network request is to query the specific contract status at a specific block height in the second smart contract, the cross-subnet response will contain the corresponding specific contract status. After the second subnet node obtains the cross-subnet response, also for the sake of cross-subnet communication security, it will process the second trusted execution environment based on the second public key pair corresponding to the first trusted execution environment. The cross-subnet response is encrypted to obtain the encrypted response, and then the encrypted response is output to the second trusted execution environment and called back to the first subnet node. At this time, the encrypted response is transmitted outside the trusted execution environment even if Captured by a third party, the third party will also be unable to decrypt and restore it to a clear text cross-subnet response due to the lack of the second private key, thereby ensuring the security of the cross-subnet communication process. This encrypted response is also a type of Privacy Transactions.

In the embodiment of this specification, the second smart contract is run in the second trusted execution environment by the second subnet node by loading the second smart contract program in the second trusted execution environment, where the second smart contract program The second subnet node decrypts the second smart contract program ciphertext read from outside the second trusted execution environment in the second trusted execution environment. The second smart contract runs in the second trusted execution environment, which is actually the result of the second subnet node loading the second smart contract program in the second trusted execution environment. Since the second trusted execution environment is essentially a period In a physically isolated execution environment, all running programs are loaded in isolated memory. Therefore, persistent storage is required for programs that do not need to run in a second trusted execution environment for the time being. In order to ensure information security, any program running in the second trusted execution environment follows the principle of "decryption and loading inside the trusted execution environment, and optional encrypted storage outside the execution environment". Therefore, the essence of the second smart contract program The above is the result of decrypting the second smart contract program ciphertext read from outside the second trusted execution environment and inside the second trusted execution environment. For example, when the second subnet node receives the encrypted message and decrypts it in the second trusted execution environment to obtain a cross-subnet request, it is further found that the cross-subnet request is a cross-subnet request for calling the second smart contract. request, then the second subnet node can directly call the second smart contract running in the second trusted execution environment to execute the cross-subnet request, or read the second smart program ciphertext from outside the second trusted execution environment. After decrypting the second smart contract program into the second trusted execution environment through the first private key, the second smart contract program is temporarily loaded in the second trusted execution environment to realize running in the second trusted execution environment. The second smart contract finally calls the second smart contract in the running state to execute the cross-subnet request. Similar to the first smart contract, the second smart contract is also a privacy contract.

The process of the second subnet node sending an encrypted response to the first subnet node is similar to the process of the first subnet node sending an encrypted request to the second subnet node. Both are based on cross-subnet communication. The detailed process is I won’t go into details here.

S206: Read the encrypted response into the first trusted execution environment, and decrypt 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 answer.

After the first subnet node receives the encrypted response, it can read it into the first trusted execution environment, and use the second private key uniquely held by the first trusted execution environment in the first trusted execution environment Decrypt encrypted responses to obtain cross-subnet responses. So far, the embodiments of this specification have completely realized the process of the first subnet node initiating a cross-subnet call to the second subnet node.

Optionally, the cross-subnet request includes: a consensus transaction that is jointly executed by all subnet nodes in the second blockchain subnet, or a local transaction that is independently executed only by the second subnet node.

In the embodiment of this specification, the cross-subnet request may be a consensus transaction or a local transaction. Among them, when the cross-subnet request is a consensus transaction, when the second subnet node receives the cross-subnet request, the cross-subnet request will be processed in the second blockchain subnet like an ordinary blockchain transaction. Consensus, execution, block formation and uploading to the blockchain ledger, which means that all subnet nodes in the second blockchain subnet (including the second subnet node) will execute the cross-subnet request to generate the corresponding Cross-subnet response, while changing the world state of the second blockchain subnet, and returning the corresponding cross-subnet response through one of the elected subnet nodes (for example, the second subnet node).

The local transactions involved in the embodiments of this specification refer to transactions that do not participate in blockchain consensus, block formation, and on-chain, and are only used as an internal calling medium; in the case of a cross-subnet request for a local transaction, when the third After the second subnet node receives the cross-subnet request, the second subnet node will independently execute the cross-subnet request to generate the corresponding cross-subnet response. There will be no consensus or change of the world state, but only after the execution is completed locally. Return the cross-subnet response to the first subnet node in a callback manner. Since cross-subnet requests as local transactions do not require consensus, block formation, and chaining, the embodiments of this specification can limit the calculation amount within the second subnet node, reducing the overall response of the second blockchain network to cross-subnet requests. Reduce the computational burden of subnet requests and improve the execution efficiency of cross-subnet requests.

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

As shown in Figure 3, Figure 3 is an application scenario diagram based on Figure 1, using nodeC1 as the first subnet node and nodeE2 as the second subnet node. They are deployed as a first subnet node and a second subnet node. In the embodiments of different node devices, nodeC belonging to subnet0, nodeC1 belonging to subnet1, and nodeC2 belonging to subnet2 are simultaneously deployed on node device 3, where nodeC, nodeC1, and nodeC2 are specifically virtual machines deployed locally by node device 3. A blockchain node instance formed by running the pre-deployed blockchain platform code (hereinafter referred to as the blockchain node), and the relevant data of nodeC as a blockchain node during the running process is saved in the database corresponding to nodeC, nodeC1 Relevant data related to nodeC2 as other blockchain nodes during operation are stored separately in the databases corresponding to nodeC1 and nodeC2. Similarly, nodeE belonging to subnet0 and nodeE2 belonging to subnet2 are deployed on node device 5 at the same time. In addition, any node device can be deployed with blockchain consensus code, and the node device can run the consensus code to form a consensus component instance locally; and, the node device can also be deployed with P2P (Peer to Peer) managed in the form of plug-ins. , peer-to-peer network communication) component code, the node device can run the P2P component code to form a P2P component instance locally, that is, a P2P plug-in. For example, in Figure 3, node device 3 and node device 5 both run P2P plug-ins locally. The P2P plug-in can be shared and used by different blockchain nodes on the same node device. For example, nodeC, nodeC1 and nodeC2 in node device 3 can call the same P2P plug-in running on node device 3 to share its functions and data, for example Implement cross-subnet communication. nodeC1 maintains a first trusted execution environment. The first smart contract deployed by nodeC1 can run in the first trusted execution environment in plain text. Similarly, nodeE2 also maintains a second trusted execution environment. The first smart contract deployed by nodeE2 The second smart contract can also run in the second trusted execution environment in plain text. In the embodiment of this specification, cross-subnet communication between the first subnet node and the second subnet node is specifically communication across node devices, and the transmission data may pass through the first subnet node and the second subnet node during the routing process. Node devices other than the node devices where the subnet nodes are located respectively.

As shown in Figure 4, Figure 4 is an application scenario diagram based on Figure 1, using nodeC1 as the first subnet node and nodeC2 as the second subnet node. They are deployed as a first subnet node and a second subnet node. In the embodiment of the same node device, nodeC belonging to subnet0, nodeC1 belonging to subnet1, and nodeC2 belonging to subnet2 are simultaneously deployed on node device 3. Node device 3 runs a P2P plug-in locally, and the P2P plug-in can be used by node device 3 nodeC, nodeC1 and nodeC2 share data and functions. In the embodiment of this specification, multiple trusted execution environments (first trusted execution environment and second trusted execution environment) are maintained in the same node device (node device 3), and nodeC1 maintains the first trusted execution environment, The first smart contract deployed by nodeC1 can run in the first trusted execution environment in plain text. nodeC2 also maintains a second trusted execution environment. The second smart contract deployed by nodeC2 can also run in the third trusted execution environment in clear text. 2. In a trusted execution environment. In the embodiment of this specification, the cross-subnet communication between the first subnet node and the second subnet node is specifically the cross-process communication within the node device, and the transmitted data will not pass through the first subnet node and the second subnet node. Other node devices other than the node device where the network node is located together will only be transferred between the first subnet node and the second subnet node through the P2P plug-in running locally on the node device.

Optionally, it also includes: reading the cross-subnet transaction ciphertext into the first trusted execution environment, decrypting the cross-subnet transaction ciphertext in the first trusted execution environment to obtain the cross-subnet transaction, and calling A first smart contract executes the cross-subnet transaction to generate the cross-subnet request.

In the embodiment of this specification, the first smart contract is the cross-subnet request generated when executing a cross-subnet transaction, and the cross-subnet request is read from outside the first trusted execution environment. The cross-subnet transaction ciphertext is decrypted inside the first trusted execution environment. Specifically, the transaction initiator can initiate a cross-subnet transaction ciphertext to the first blockchain network, and the cross-subnet transaction ciphertext is generated by each subnet node in the first blockchain network (including the first subnet node). ) for consensus and execution. When the first subnet node needs to execute the cross-subnet transaction ciphertext, it needs to first read the cross-subnet transaction ciphertext into the first trusted execution environment for decryption (for example, decryption based on the second private key ) to obtain a cross-subnet transaction, and then directly call the first smart contract running in the first trusted execution environment to execute the cross-subnet transaction, or read the first smart program ciphertext from outside the first trusted execution environment After decrypting the first smart contract program into the first trusted execution environment through the first private key, the first smart contract program is temporarily loaded in the first trusted execution environment to realize running in the first trusted execution environment. The first smart contract finally calls the first smart contract in the running state to execute the cross-subnet transaction to generate a cross-subnet request. The cross-subnet transactions involved in the embodiments of this specification are private transactions.

Figure 5 is a flow chart of another cross-subnet calling method provided by an exemplary embodiment. The method is applied to a second subnet node in a second blockchain subnet managed by a blockchain mainnet, the second subnet node maintains a second trusted execution environment, and the blockchain mainnet also manages There is a first blockchain subnet, and the first subnet node in the first blockchain subnet maintains a first trusted execution environment; the method includes S502 to S506.

S502: Receive an encryption request obtained by encrypting a 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 made by The first subnet node is generated by running the first smart contract in the first trusted execution environment.

S504: Read the encrypted request into the second trusted execution environment, and decrypt 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, execute the cross-subnet request to generate a corresponding cross-subnet response, and encrypt the cross-subnet response based on the second public key corresponding to the first trusted execution environment to obtain an encrypted response.

S506: 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 executes the encrypted response in the first trusted execution environment based on the first trusted execution environment. A second private key corresponding to a trusted execution environment decrypts the encrypted response to obtain the cross-subnet response.

Figure 6 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to Figure 6. At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608 and a non-volatile memory 610. Of course, it may also include other hardware required for services. One or more embodiments of this specification may be implemented based on software. For example, the processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs it. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each A logic unit can also be a hardware or logic device.

As shown in Figure 7, Figure 6 is a block diagram of a cross-subnet calling device provided in this specification according to an exemplary embodiment. This device can be applied to the equipment shown in Figure 6 to implement the technical solution of this specification. ; The device is applied to the first subnet node in the first blockchain subnet managed by the blockchain main network. The first subnet node maintains a first trusted execution environment, and the blockchain main network A second blockchain subnet is also managed, and the second subnet node in the second blockchain subnet maintains a second trusted execution environment; the device includes: an encryption request acquisition unit 701, configured to obtain a second trusted execution environment in the first trusted execution environment. Run the first smart contract in the execution environment to generate a cross-subnet request, and encrypt the cross-subnet request in the first trusted execution environment based on the first public key corresponding to the second trusted execution environment to obtain an encrypted request; The request sending unit 702 is configured to send the encryption request to the second subnet node and receive the encrypted response returned by the second subnet node. The encrypted response is obtained by the second subnet node in the following manner: The encrypted request is read into the second trusted execution environment, and the encrypted request is decrypted 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, and the Make a cross-subnet request to generate a corresponding cross-subnet response, and encrypt the cross-subnet response based on the second public key corresponding to the first trusted execution environment to obtain the encrypted response; the encrypted response decryption unit 703 is used to The encrypted response is read into the first trusted execution environment, and the encrypted response is decrypted 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.

Optionally, the first smart contract is run by the first subnet node in the first trusted execution environment by loading the first smart contract program in the first trusted execution environment, where the first smart contract program is executed by the first trusted execution environment. The subnet node decrypts the first smart contract program ciphertext read from outside the first trusted execution environment in the first trusted execution environment.

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

Optionally, the second smart contract is run in the second trusted execution environment by the second subnet node by loading the second smart contract program in the second trusted execution environment, where the second smart contract program is run by the second The subnet node decrypts the second smart contract program ciphertext read from outside the second trusted execution environment in the second trusted execution environment.

Optionally, it also includes: a cross-subnet transaction execution unit 704, configured to read the cross-subnet transaction ciphertext into the first trusted execution environment, and execute the cross-subnet transaction ciphertext in the first trusted execution environment. Decrypt to obtain the cross-subnet transaction, and call the first smart contract to execute the cross-subnet transaction to generate the cross-subnet request.

As shown in Figure 8, Figure 8 is a block diagram of another cross-subnet calling device provided in this specification according to an exemplary embodiment. This device can be applied to the equipment shown in Figure 6 to implement the technology of this specification. Solution; the device is applied to a second subnet node in a second blockchain subnet managed by the blockchain main network. The second subnet node maintains a second trusted execution environment. The blockchain main network The 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 includes: an encryption request receiving unit 801 for receiving the first subnet The network node encrypts the cross-subnet request 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 the first subnet node in the first trusted execution environment. Generated by running the first smart contract in the first trusted execution environment; the encrypted response acquisition unit 802 is used to read the encrypted request into the second trusted execution environment, based on the second trusted execution environment in the second trusted execution environment. The first private key corresponding to the execution environment decrypts the encrypted request to obtain the cross-subnet request, executes the cross-subnet request to generate a corresponding cross-subnet response, and generates a corresponding cross-subnet response based on the first trusted execution environment corresponding to the first private key. The two public keys encrypt the cross-subnet response to obtain an encrypted response; the encrypted response sending unit 803 is used to send the encrypted response to the first subnet node, so that the first subnet node will receive the encrypted response. The encrypted response is read into the first trusted execution environment, and the encrypted response is decrypted 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 1990s, improvements in a technology could be clearly distinguished as hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method processes). However, with the development of technology, many improvements in today's method processes can be regarded as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement of a method flow cannot be implemented using hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic functions are determined by the user programming the device. Designers can program themselves to "integrate" a digital system on a PLD, instead of asking chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing, and before compilation The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL), and HDL is not just one kind, but there are many, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used The two are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that by simply logically programming the method flow using the above-mentioned hardware description languages and programming it into the integrated circuit, the hardware circuit that implements the logical method flow can be easily obtained.

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 (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, the present invention does not exclude that with the development of computer technology in the future, the computer that implements the functions of the above 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, or a personal digital assistant. , media player, navigation device, email device, game console, tablet, wearable device, or a combination of any of these devices.

Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-inventive means. The sequence of steps listed in the embodiment is only one way of executing the sequence of many steps, and does not represent the only execution sequence. When the actual device or terminal product is executed, it may be executed sequentially or in parallel according to the methods shown in the embodiments or figures (for example, a parallel processor or a multi-thread processing environment, or even a distributed data processing environment). The terms "comprises," "comprises" or any other variation thereof are intended to cover a non-exclusive inclusion such that a process, method, product or apparatus including a list of elements includes not only those elements but also others not expressly listed elements, or also elements inherent to the process, method, product or equipment. Without further limitation, it does not exclude the presence of additional identical or equivalent elements in a process, method, product or apparatus including the stated elements. For example, if the words "first" and "second" are used to express names, they do not indicate any specific order.

For the convenience of description, when describing the above device, the functions are divided into various modules and described separately. Of course, when implementing one or more of this specification, the functions of each module can be implemented in the same or multiple software and/or hardware, or the modules that implement the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. . The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

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 process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations 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 device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing apparatus to operate in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction means, the instructions The device implements the functions specified in a process or processes of the flowchart and/or a block or blocks of the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

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

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and 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 disc (DVD) or other optical storage, Magnetic tape, magnetic tape storage, graphene storage or other magnetic storage devices or any other non-transmission medium can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should be understood by those skilled in the art that 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 that combines software and hardware aspects. Furthermore, one or more embodiments of the present description may employ a computer program implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein. Product form.

One or more embodiments of this 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 specific tasks or implement specific abstract data types. One or more embodiments of the present specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on its differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the partial description of the method embodiment. In the description of this specification, reference to the terms "one embodiment," "some embodiments," "an example," "specific examples," or "some examples" or the like means that specific features are described in connection with the embodiment or example. , structures, materials or features are included in at least one embodiment or example of this specification. In this specification, the schematic expressions of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the specific features, structures, materials or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and combine different embodiments or examples and features of different embodiments or examples described in this specification unless they are inconsistent with each other.

The above descriptions are only examples of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. To those skilled in the art, various modifications and changes may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification shall be included in the scope of the claims.

Claims

A cross-subnet calling method is applied to the first subnet node in the first blockchain subnet managed by the blockchain mainnet. The first subnet node maintains a first trusted execution environment, and the zone The main blockchain network also manages a second blockchain subnet, and the second subnet node in the second blockchain subnet maintains a second trusted execution environment; the method includes:

Run the first smart contract in the first trusted execution environment to generate a cross-subnet request, and encrypt the cross-subnet request in the first trusted execution environment based on the first public key corresponding to the second trusted execution environment Get encrypted request;

Send the encryption request to the second subnet node, and receive an encrypted response returned by the second subnet node. The encrypted response is obtained by the second subnet node in the following manner: reading the encryption request into a second accessible Trust execution environment, in the second trusted execution environment, decrypt the encrypted request based on the first private key corresponding to the second trusted execution environment to obtain the cross-subnet request, execute the cross-subnet request to generate the corresponding A cross-subnet response, and encrypting the cross-subnet response based on the second public key corresponding to the first trusted execution environment to obtain the encrypted response;

The encrypted response is read into the first trusted execution environment, and the encrypted response is decrypted 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.
According to the method of claim 1, the first smart contract is run in the first trusted execution environment by the first subnet node by loading the first smart contract program in the first trusted execution environment, wherein the first smart contract The contract program is obtained by decrypting the first smart contract program ciphertext read from outside the first trusted execution environment by the first subnet node in the first trusted execution environment.
According to the method of claim 1, the cross-subnet response is generated by a second smart contract running in a second trusted execution environment executing the cross-subnet request.
According to the method of claim 3, the second smart contract is run in the second trusted execution environment by the second subnet node by loading the second smart contract program in the second trusted execution environment, wherein the second smart contract The contract program is obtained by decrypting the second smart contract program ciphertext read from outside the second trusted execution environment by the second subnet node in the second trusted execution environment.
According to the method of claim 1, the cross-subnet request includes: a consensus transaction jointly executed by all subnet nodes in the second blockchain subnet, or a local transaction independently executed only by the second subnet node.
According to the method of claim 1, the first subnet node and the second subnet node are deployed on the same or different node devices.
The method of claim 1, further comprising:

Read the cross-subnet transaction ciphertext into the first trusted execution environment, decrypt the cross-subnet transaction ciphertext in the first trusted execution environment to obtain the cross-subnet transaction, and call the first smart contract to execute the Cross-subnet transaction to generate said cross-subnet request.
A cross-subnet calling method is applied to a second subnet node in a second blockchain subnet managed by the blockchain mainnet. The second subnet node maintains a second trusted execution environment, and the zone 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 method includes:

Receive an encryption request obtained by encrypting a 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 the first Generated by the subnet node running the first smart contract in the first trusted execution environment;

The encrypted request is read into the second trusted execution environment, and the encrypted request is decrypted 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, Execute the cross-subnet request to generate a corresponding cross-subnet response, and encrypt the cross-subnet response based on the second public key corresponding to the first trusted execution environment to obtain an encrypted response;

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 executes the encrypted response in the first trusted execution environment based on the first trustworthy execution environment. The second private key corresponding to the execution environment is used to decrypt the encrypted response to obtain the cross-subnet response.
A cross-subnet calling device is applied to a first subnet node in a first blockchain subnet managed by a blockchain mainnet. The first subnet node maintains a first trusted execution environment, and the zone The main blockchain network also manages a second blockchain subnet, and the second subnet node in the second blockchain subnet maintains a second trusted execution environment; the device includes:

An encryption request acquisition unit, configured to run the first smart contract in the first trusted execution environment to generate a cross-subnet request, in the first trusted execution environment based on the first public key pair corresponding to the second trusted execution environment. The above cross-subnet request is encrypted to obtain the encrypted request;

An encryption request sending unit, configured to send the encryption request to the second subnet node and receive an encrypted response returned by the second subnet node. The encrypted response is obtained by the second subnet node in the following manner: The encrypted request is read into the second trusted execution environment, and the encrypted request is decrypted 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, and the Make a cross-subnet request to generate a corresponding cross-subnet response, and encrypt the cross-subnet response based on the second public key corresponding to the first trusted execution environment to obtain the encrypted response;

The encrypted response decryption unit is used to read the encrypted response into the first trusted execution environment, and decrypt the encrypted response in the first trusted execution environment based on the second private key corresponding to the first trusted execution environment. The cross-subnet response.
A cross-subnet calling device is applied to a second subnet node in a second blockchain subnet managed by the blockchain main network. The second subnet node maintains a second trusted execution environment, and the zone 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 includes:

An encryption request receiving unit, configured to receive an encryption request obtained by encrypting a 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 The cross-subnet request is generated by the first subnet node running the first smart contract in the first trusted execution environment;

An encrypted response acquisition unit, configured to read the encrypted request into a second trusted execution environment, and decrypt the encrypted request in the second trusted execution environment based on the first private key corresponding to the second trusted execution environment. The cross-subnet request is executed to generate a corresponding cross-subnet response, and the cross-subnet response is encrypted based on the second public key corresponding to the first trusted execution environment to obtain an encrypted response;

An encrypted response sending unit, 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 executes the encrypted response in the first trusted execution environment. The encrypted response is decrypted in the execution environment based on the second private key corresponding to the first trusted execution environment to obtain the cross-subnet response.
An electronic device including:

processor;

Memory used to store instructions executable by the processor;

Wherein, the processor implements the method according to any one of claims 1-8 by running the executable instructions.
A computer-readable storage medium having computer instructions stored thereon, which when executed by a processor, implements the steps of the method according to any one of claims 1-8.