WO2024001022A1 - Appel inter-sous-réseau - Google Patents

Appel inter-sous-réseau Download PDF

Info

Publication number
WO2024001022A1
WO2024001022A1 PCT/CN2022/135244 CN2022135244W WO2024001022A1 WO 2024001022 A1 WO2024001022 A1 WO 2024001022A1 CN 2022135244 W CN2022135244 W CN 2022135244W WO 2024001022 A1 WO2024001022 A1 WO 2024001022A1
Authority
WO
WIPO (PCT)
Prior art keywords
subnet
execution environment
trusted execution
node
blockchain
Prior art date
Application number
PCT/CN2022/135244
Other languages
English (en)
Chinese (zh)
Inventor
黄祖城
Original Assignee
蚂蚁区块链科技(上海)有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 蚂蚁区块链科技(上海)有限公司 filed Critical 蚂蚁区块链科技(上海)有限公司
Publication of WO2024001022A1 publication Critical patent/WO2024001022A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption

Definitions

  • 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.
  • Blockchain is a new application model of computer technology such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • 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.
  • 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.
  • the purpose of the present invention is to provide a cross-subnet calling method, device, electronic device and storage medium.
  • 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
  • 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.
  • 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
  • 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.
  • 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
  • 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 obtained by
  • 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.
  • 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
  • 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.
  • 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.
  • an electronic device 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.
  • a computer-readable storage medium 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.
  • the first subnet node and the second subnet node are in different blockchain subnets respectively.
  • a cross-subnet call is made between the first subnet node and the second subnet node.
  • 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.
  • 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.
  • all blockchain nodes in the blockchain network maintain the same block data, which cannot meet the special needs of some nodes.
  • all alliance members i.e., node members within the alliance
  • All alliance members 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.
  • 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.
  • 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.
  • 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 Two blockchain nodes.
  • the blockchain main network is subnet0
  • the blockchain nodes included in subnet0 are nodeA, nodeB, nodeC, nodeD, nodeE, etc.
  • 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.
  • the blockchain node that initiates the transaction to establish the blockchain subnet does not necessarily participate in the formed blockchain subnet.
  • 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.
  • 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.
  • the blockchain mainnet in this specification can also be a subnet of other blockchain networks.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • the node members of the blockchain subnet are not necessarily only some of the node members of the blockchain mainnet.
  • the node members of the blockchain subnet can be completely consistent with the node members of the blockchain main network.
  • 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.
  • 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.
  • 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.
  • 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.
  • the contract called can be the aforementioned creation contract or system contract
  • the method called can be a method of establishing a blockchain subnet
  • the parameters passed in can include the above configuration information.
  • the transaction may include the following information:
  • 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.
  • 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.
  • genesis is used to represent this The value of the parameter, the genesis is specifically the aforementioned configuration information.
  • nodeA ⁇ nodeE 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.
  • 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:
  • 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.
  • 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.
  • this implementation method based on listening code is relatively more proactive compared to the event mechanism.
  • 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.
  • 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.
  • the content of the topic is the keyword subnet, and this keyword is different from the topic in the event generated by other methods.
  • 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.
  • the events in the receipt are as follows:
  • the content of the data field may include:
  • nodeA's public key nodeA's IP, nodeA's port number...
  • nodeB s public key, nodeB’s IP, nodeB’s port number...;
  • nodeD s public key, nodeD’s IP, nodeD’s port number...;
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • the execution results of the contract can include the genesis block.
  • 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.
  • the node device creates a first instance in the above process, and the first instance runs the blockchain platform code.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a blockchain subnet can be created on the blockchain mainnet.
  • subnet0 originally contains nodeA ⁇ nodeE
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • blockchain subnets can also be created through other means and made subject to the management of the blockchain main network.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first blockchain subnet and the second blockchain subnet are called TEE (Trusted Execution Environment, Trusted Execution Environment) chain.
  • 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.
  • cross-subnet communication it is necessary to encrypt them in the trusted execution environment before proceeding. Communication across subnets.
  • 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.
  • 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.
  • 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.
  • 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.
  • the cross-subnet request 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. .
  • 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.
  • 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.
  • 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.
  • the first subnet node 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.
  • 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.
  • nodeC1 wants to send an encryption request to nodeE2.
  • 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.
  • 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.
  • 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
  • P2P Peer to Peer, peer-to-peer network communication
  • 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.
  • 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.
  • the second subnet node 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.
  • the second subnet node 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.
  • the cross-subnet response 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.
  • the second subnet node 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second smart contract program 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.
  • the first subnet node 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.
  • the first subnet node and the second subnet node are in different blockchain subnets respectively.
  • a cross-subnet call is made between the first subnet node and the second subnet node.
  • 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.
  • 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.
  • the cross-subnet request may be a consensus transaction or a local transaction.
  • the cross-subnet request 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.
  • 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.
  • the first subnet node and the second subnet node are deployed on the same or different node devices.
  • 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.
  • 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.
  • 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.
  • P2P peer to Peer
  • the node device can run the P2P component code to form a P2P component instance locally, that is, a P2P plug-in.
  • P2P plug-in can be shared and used by different blockchain nodes on the same node device.
  • 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.
  • 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.
  • 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.
  • 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.
  • multiple trusted execution environments 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first subnet node 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.
  • the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608 and a non-volatile memory 610.
  • the processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs it.
  • the execution subject of the following processing flow is not limited to each A logic unit can also be a hardware or logic device.
  • 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.
  • 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.
  • 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.
  • the cross-subnet response is generated by the second smart contract running in the second trusted execution environment executing the cross-subnet request.
  • 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.
  • 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.
  • the first subnet node and the second subnet node are deployed on the same or different node devices.
  • 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.
  • 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 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.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • 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.
  • 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.
  • the controller 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.
  • 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.
  • the functions are divided into various modules and described separately.
  • 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.
  • the division of the units is only a logical function division. In actual implementation, there may be other division methods.
  • multiple units or components may be combined or integrated. to another system, or some features can be ignored, or not implemented.
  • 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.
  • 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.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • 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.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • 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.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • 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.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • 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.
  • 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.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un procédé et un appareil d'appel inter-sous-réseau, un dispositif électronique et un support de stockage. Le procédé est appliqué à un premier nœud de sous-réseau d'un premier sous-réseau de chaîne de blocs géré par un réseau principal de chaîne de blocs ; le premier nœud de sous-réseau maintient un premier environnement d'exécution de confiance, le réseau principal de chaîne de blocs gère également un second sous-réseau de chaîne de blocs, et un second nœud de sous-réseau du second sous-réseau de chaîne de blocs maintient un second environnement d'exécution de confiance. Le procédé consiste à : exécuter un premier contrat intelligent dans le premier environnement d'exécution de confiance pour générer une demande inter-sous-réseau et la chiffrer pour obtenir une demande chiffrée ; envoyer la demande chiffrée au second nœud de sous-réseau, et recevoir une réponse chiffrée renvoyée par le second nœud de sous-réseau, la réponse chiffrée étant obtenue par le second nœud de sous-réseau au moyen de l'approche suivante consistant à : lire la demande chiffrée dans le second environnement d'exécution de confiance à des fins de déchiffrement pour obtenir la demande inter-sous-réseau, exécuter la demande inter-sous-réseau pour générer une réponse inter-sous-réseau correspondante, et la chiffrer pour obtenir la réponse chiffrée ; et lire la réponse chiffrée dans le premier environnement d'exécution de confiance à des fins de déchiffrement pour obtenir la réponse inter-sous-réseau.
PCT/CN2022/135244 2022-06-29 2022-11-30 Appel inter-sous-réseau WO2024001022A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210759288.5 2022-06-29
CN202210759288.5A CN115134075A (zh) 2022-06-29 2022-06-29 跨子网调用方法、装置、电子设备和存储介质

Publications (1)

Publication Number Publication Date
WO2024001022A1 true WO2024001022A1 (fr) 2024-01-04

Family

ID=83382747

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/135244 WO2024001022A1 (fr) 2022-06-29 2022-11-30 Appel inter-sous-réseau

Country Status (2)

Country Link
CN (1) CN115134075A (fr)
WO (1) WO2024001022A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115134075A (zh) * 2022-06-29 2022-09-30 蚂蚁区块链科技(上海)有限公司 跨子网调用方法、装置、电子设备和存储介质
CN115378942B (zh) * 2022-10-10 2022-12-20 北京理工大学 一种区块链的信息跨链交互方法和交互装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111095256A (zh) * 2019-04-26 2020-05-01 阿里巴巴集团控股有限公司 在可信执行环境中安全地执行智能合约操作
CN112948153A (zh) * 2021-05-14 2021-06-11 支付宝(杭州)信息技术有限公司 一种消息跨链传输的方法和装置
CN114255031A (zh) * 2020-09-23 2022-03-29 华为技术有限公司 用于执行交易的跨区块链的系统、跨链交易方法及设备
CN114679274A (zh) * 2021-12-31 2022-06-28 支付宝(杭州)信息技术有限公司 跨子网交互的权限控制方法及装置、电子设备、存储介质
CN115134075A (zh) * 2022-06-29 2022-09-30 蚂蚁区块链科技(上海)有限公司 跨子网调用方法、装置、电子设备和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111095256A (zh) * 2019-04-26 2020-05-01 阿里巴巴集团控股有限公司 在可信执行环境中安全地执行智能合约操作
CN114255031A (zh) * 2020-09-23 2022-03-29 华为技术有限公司 用于执行交易的跨区块链的系统、跨链交易方法及设备
CN112948153A (zh) * 2021-05-14 2021-06-11 支付宝(杭州)信息技术有限公司 一种消息跨链传输的方法和装置
CN114679274A (zh) * 2021-12-31 2022-06-28 支付宝(杭州)信息技术有限公司 跨子网交互的权限控制方法及装置、电子设备、存储介质
CN115134075A (zh) * 2022-06-29 2022-09-30 蚂蚁区块链科技(上海)有限公司 跨子网调用方法、装置、电子设备和存储介质

Also Published As

Publication number Publication date
CN115134075A (zh) 2022-09-30

Similar Documents

Publication Publication Date Title
CN111541727B (zh) 区块链一体机及其自动建链方法、装置
CN113259455B (zh) 跨子网交互方法及装置
WO2024001022A1 (fr) Appel inter-sous-réseau
CN111541724B (zh) 区块链一体机及其节点自动加入方法、装置
US11451404B2 (en) Blockchain integrated stations and automatic node adding methods and apparatuses
CN113259460B (zh) 跨链交互方法及装置
CN113259456B (zh) 跨链交互方法及装置
CN113329030A (zh) 区块链一体机及其密码加速卡、密钥管理方法和装置
WO2023124746A1 (fr) Commande d'autorisation d'interaction inter-sous-réseau
CN113067897B (zh) 跨链交互方法及装置
WO2023124744A1 (fr) Interaction inter-sous-réseau
CN114363335B (zh) 跨链交互方法及装置
WO2023050966A1 (fr) Vérification de données de chaîne de blocs
CN114374699B (zh) 跨链交互方法和跨链交互的审计方法
CN113259461B (zh) 跨链交互方法和区块链系统
CN113259464B (zh) 组建区块链子网的方法和区块链系统
CN113259118B (zh) 同步节点信息列表的方法
CN113259117B (zh) 同步节点信息列表的方法
WO2024001037A1 (fr) Procédé et appareil de transmission de message, dispositif électronique et support de stockage
CN114095507B (zh) 跨链交互方法和区块链系统
CN114422520B (zh) 跨链交互方法及装置
CN113067903B (zh) 组建区块链子网的方法和区块链系统
Blömer et al. Attribute-based encryption as a service for access control in large-scale organizations
CN116455900A (zh) 一种跨子网交互方法及装置、区块链系统
CN116366706A (zh) 跨链交互方法和区块链节点

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22949102

Country of ref document: EP

Kind code of ref document: A1