WO2020199177A1

WO2020199177A1 - Method and apparatus for running smart contract

Info

Publication number: WO2020199177A1
Application number: PCT/CN2019/081423
Authority: WO
Inventors: 谢美伦
Original assignee: 华为技术有限公司
Priority date: 2019-04-04
Filing date: 2019-04-04
Publication date: 2020-10-08
Also published as: CN112567414A

Abstract

Disclosed is an apparatus (300) for running a smart contract, which can be applied to a blockchain network (140). By means of the apparatus (300) for running a smart contract, execution environments at different security levels are provided for a smart contract, such that when an execution environment is configured for the smart contract, the execution environment that satisfies a security level requirement of the smart contract for the execution environment can be configured for the smart contract according to a predefined rule, so as to run the smart contract in the execution environment, thereby improving the security when the smart contract is run.

Description

Method and device for running smart contract

Technical field

This application relates to the field of blockchain technology, and more specifically, to a method and device for running smart contracts.

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. Blockchain technology can solve the problems of high trust cost and risk of centralization.

Ethereum is an open source public blockchain platform with smart contract functions. It provides a decentralized virtual machine through its dedicated cryptocurrency Ether to process point-to-point smart contracts, becoming the blockchain 2.0 representative. A smart contract is a collection of code and data, and can also be called a "programmable contract". Generally speaking, smart contracts are defined by program coding and preset operating conditions; when the operating conditions are triggered, the behavior is executed. The "intelligence" is the execution intelligence, that is, if a certain preset condition is reached, the contract will run automatically. At this stage, the security of smart contracts in the blockchain completely depends on the security mechanism of the host's Linux/Windows system.

Summary of the invention

The present application provides a method and device for running a smart contract. The method provides an execution environment that meets the security level for the smart contract, thereby improving the security of the smart contract during operation.

In the first aspect, a device for running a smart contract is provided. The device can be applied to a blockchain network and includes an acquisition module and a processing module. Among them, the acquisition module is used to obtain a smart contract that has a security level requirement; a processing module is used to configure an execution environment for the smart contract that meets the requirements according to predefined rules; the processing module is also used to Run the smart contract in the execution environment.

Based on the above technical solution, the smart contract running device provides different security levels of execution environments for smart contracts, so that when configuring the execution environment for the smart contract, the smart contract can be configured to meet its requirements for the execution environment according to predefined rules. The execution environment required by the security level, and then the smart contract is run in the execution environment, thereby improving the security of the smart contract runtime.

For example, a system on chip (SoC) can be configured in a blockchain node. The SoC can provide at least one execution environment of Trustzone, Bowmore, or SEE formed by eSE or inSE. Trustzone or Bowmore The execution environment is called trusted execution environment (TEE), and the execution environment corresponding to eSE or inSE is called secure execution environment (SEE). In addition, the SoC can also provide a rich execution environment (rich execution environment). environment, REE). Among them, the safety level of SEE is higher than that of TEE, and the safety level of TEE is higher than that of REE.

In a possible implementation manner, the predefined rules include: different types of smart contracts correspond to execution environments of different security levels.

For example, in order to improve the security during the operation of smart contracts, the security level of the execution environment that can be configured for financial-level smart contracts is higher than the security level of the execution environment configured for system-level smart contracts, and the execution environment configured for system-level smart contracts The security level of is higher than the security level of the execution environment configured for ordinary smart contracts.

Based on the above technical solutions, by configuring execution environments of different security levels for different types of smart contracts, the execution environment configured for the smart contract meets the requirements of the smart contract for the security level of the execution environment, and then the smart contract is run in the execution environment , Thereby improving the security of smart contract runtime.

In a possible implementation manner, the smart contract has undergone an encryption operation, and the processing module is further used to perform a decryption operation on the smart contract in the execution environment.

Based on the above technical solution, in order to prevent the reverse leakage of the operation logic and data processing flow of the smart contract, the provider of the smart contract can encrypt the binary file of the smart contract after generating the binary file of the smart contract. In this case, Before the blockchain node runs the binary file of the smart contract, it first needs to decrypt the binary file of the smart contract, and the binary file of the smart contract obtained after running the decryption operation.

In a possible implementation manner, the smart contract has undergone a signature operation, and the processing module is further used to perform a verification signature operation on the smart contract in the execution environment.

Based on the above technical solutions, in order to manage the complete life cycle of a smart contract (for example, the complete life cycle of a smart contract includes deployment, storage, operation, and shutdown), a public key infrastructure (PKI) system can be used to The smart contract performs the signature operation. At this time, the blockchain node needs to verify the smart contract before running the smart contract. Only when the blockchain node passes the verification of the signed smart contract, the blockchain node Only then will the binary file of the smart contract be run to manage whether to run the smart contract.

In a possible implementation, the obtaining module is also used to: obtain a certificate revocation list CRL, in which the relevant information of the smart contract that has been revoked is stored in the CRL; the processing module is also used to: terminate according to the CRL Run the smart contract.

Based on the above technical solution, in order to manage the complete life cycle of the smart contract (for example, the complete life cycle of the smart contract includes deployment, storage, operation and shutdown), the relevant information of the revoked smart contract is added to the certificate revocation In the certificate revocation list (CRL), the blockchain node can determine whether to stop running the smart contract according to whether the CRL includes relevant information about a certain smart contract, so as to manage whether to stop running the smart contract.

In a possible implementation, the related information of the smart contract includes the serial number and revocation time of the certificate of the smart contract that has been revoked.

In a possible implementation manner, the CRL is stored in at least one of a replay protection memory block RPMB, an electrically programmable fuse Efuse module, or a one-time programmable OTP memory.

Based on the above technical solution, by storing the CRL in the RPMB, Efuse module or OTP memory, the CRL is stored in a safer storage area.

In a possible implementation, the processing module is also used to encrypt the private data generated in the blockchain using homomorphic encryption technology or zero-knowledge proof technology.

In a possible implementation, when using homomorphic encryption technology or zero-knowledge proof technology to encrypt the private data generated in the blockchain, the operator used is a hardened Pairing operator.

Based on the above technical solution, when the private data generated in the blockchain is encrypted by using homomorphic encryption technology or zero-knowledge proof technology, the operator used is a hardened Pairing operator, thereby improving the performance of the encryption service.

In a possible implementation, the predefined rule includes at least one of the following: ordinary-level smart contracts correspond to rich execution environment REE; or, system-level smart contracts correspond to trusted execution environment TEE; or, financial-level smart contracts correspond to security Execution environment SEE.

In the second aspect, a method for running a smart contract is provided. The method can be applied to a blockchain network. The method is executed by any blockchain node in the blockchain network, including: obtaining a smart contract, the smart The contract has a security level requirement; according to predefined rules, the smart contract is configured with an execution environment that meets the requirements; the smart contract is run in the execution environment.

For example, in order to improve the security during the operation of smart contracts, it is possible to configure execution environments with higher security levels for smart contracts in the blockchain nodes according to predefined rules.

Based on the above technical solution, the smart contract is configured with an execution environment that meets its security level requirements for the execution environment according to predefined rules, and then the smart contract is run in the execution environment, thereby improving the security of the smart contract during operation.

In a possible implementation manner, the smart contract has undergone an encryption operation, and the method further includes: performing a decryption operation on the smart contract in the execution environment before running the smart contract in the execution environment.

Based on the above technical solutions, in order to prevent the smart contract from being reversed to leak the smart contract’s operating logic and data processing flow, the smart contract provider can encrypt the smart contract’s binary file after generating the smart contract’s binary file. In this case, before the blockchain node runs the binary file of the smart contract, it first needs to decrypt the binary file of the smart contract, and the binary file of the smart contract obtained after the decryption operation is run.

In a possible implementation manner, the smart contract has undergone a signature operation, and the method further includes: performing a verification signature operation on the smart contract in the execution environment before running the smart contract in the execution environment.

In a possible implementation, the method further includes: obtaining a certificate revocation list CRL, in which the relevant information of the smart contract that has been revoked is stored in the CRL; and terminating the operation of the smart contract according to the CRL.

In a possible implementation, the relevant information of the smart contract includes the serial number and revocation time of the certificate of the smart contract that has been revoked.

In a possible implementation manner, the CRL is stored in a replay protected memory block (RPMB), an electrically programmable fuse Efuse module, or one-time programmable (OTP).

Based on the above technical solution, the CRL is stored in the RPMB, Efuse module or OTP memory, so that the CRL is stored in at least one of the safer storage areas.

In a possible implementation, the method further includes: using homomorphic encryption technology or zero-knowledge proof technology to encrypt the private data generated in the blockchain.

In a possible implementation manner, the predefined rule execution environment includes at least one of the following:

Ordinary-level smart contracts correspond to the rich execution environment REE; or, system-level smart contracts correspond to the trusted execution environment TEE; or, financial-level smart contracts correspond to the secure execution environment SEE.

In a third aspect, a device for running a smart contract is provided. The device can be applied to a blockchain network. The device includes: a memory for storing programs; a processor for executing programs stored in the memory. When the program is executed, the processor is used to execute the method in the first aspect or each implementation manner of the first aspect. The processor includes CPU and SE. CPU is used to form TEE and REE, SE is used to form SEE.

In a fourth aspect, a computer-readable medium is provided, and the computer-readable medium stores program code for device execution, and the program code includes a method for executing the first aspect or each implementation manner of the first aspect.

In a fifth aspect, a computer program product containing instructions is provided. When the computer program product runs on a computer, the computer executes the method in the first aspect or the implementation manners of the first aspect.

In a sixth aspect, a device for running a smart contract is provided. The device can be applied to a blockchain network. The device includes a CPU and an SE, and is used to jointly execute the method in the first aspect or the implementation manners of the first aspect.

On the basis of the implementation manners provided by the above aspects, this application can be further combined to provide more implementation manners.

Description of the drawings

Figure 1 is a schematic block diagram of a system architecture applicable to the present application;

Figure 2 is a schematic flow chart of the method for running a smart contract provided by the present application;

FIG. 3 is a simplified schematic diagram of a software system architecture provided by an embodiment of the present application;

4 is a schematic block diagram of a device for running a smart contract provided by an embodiment of the application;

Fig. 5 is another schematic block diagram of a device for running a smart contract provided by an embodiment of the application.

detailed description

The technical solution in this application will be described below in conjunction with the drawings. Before that, firstly, the following terms involved in the embodiments of the present application will be briefly introduced.

The provider of a smart contract can be a person or unit that has the right to allow others to use the smart contract. For example, the provider of a smart contract can be the author of the smart contract. Smart contract is a concept in the blockchain. It is a computer protocol that spreads, verifies, or executes the contract in an informatized manner, or a set of commitments defined in digital form, including an agreement on which contract participants can execute these commitments .

The management center can be a hairstyle platform for smart contracts. For example, the provider of the smart contract can publish and license the smart contract in the management center, and the user can browse, view, and download the smart contract in the management center.

The following describes the system architecture applicable to the embodiment of the present application with reference to FIG. 1. The network architecture shown in FIG. 1 includes a smart contract provider 110, a management center 120, a subscriber 130, and a blockchain network 140. The blockchain network includes multiple blockchain nodes, for example, the blockchain network 140 Including

blockchain nodes

1401, 1402 and 1403.

The provider 110 of the smart contract can provide an installable smart contract to the management center 120, and the provider 110 of the smart contract has the right to allow others to obtain the smart contract. For example, the provider 110 of the smart contract can obtain permission from the author of the smart contract. Others obtain the right of their smart contract, so that the smart contract provider 110 has the right to allow others to use the smart contract. The user 130 can install a smart contract for a specific blockchain node through the management center 120.

In the embodiment of the present application, the communication in the system architecture and the communication between the smart contract provider 110, the user 130 and the management center 120 can be based on any wired and/or wireless network, including but not limited to the Internet, wide area network, city Local area network, local area network, virtual private network, etc.

In the embodiment of the present application, each blockchain node in the blockchain network 140 may be an electronic device, for example, it may be a fixed device or a mobile device, where the fixed device may be, for example, a server or a desktop computer, or a mobile device. For example, it can be a smart phone, a tablet computer, a portable computer, etc.

The following describes the method 200 for running a smart contract provided by an embodiment of the present application with reference to FIG. 2. FIG. 2 shows a schematic flowchart of the method 200 for running a smart contract provided by an embodiment of the present application. The method includes at least steps 201 to 203.

Step 201: Obtain a smart contract, which has a security level requirement, that is, a security requirement. The security requirement can be built into the device in the form of parameters, specifically in the cache or storage unit of the device, or the security requirement of the smart contract can be carried in the smart contract so that the device can obtain the security requirement. For example, the parameter built into the device may be a lookup table. After the acquired smart contract is acquired by the device, the security requirements corresponding to the smart contract can be found through the lookup table. In this field, because a smart contract is a secure protocol, obtaining a smart contract can be considered as Aberco’s obtaining the basic information and parameters of the smart contract, that is, the type, application scenario, function, version or some other basic parameters of the contract. In order to judge its safety requirements accordingly. Or, obtaining the smart contract may include directly obtaining the security requirements. In addition, obtaining a smart contract may also include obtaining a complete smart contract, for example, directly obtaining a smart contract issued by a smart contract provider or a management center.

Step 202: Configure an execution environment that meets the requirement for the smart contract according to a predefined rule.

Step 203: Run the smart contract in the execution environment. The foregoing execution environment may include a rich execution environment (REE), a trusted execution environment (TEE), and a secure execution environment (SEE). Among them, the safety level of SEE is higher than that of TEE, and the safety level of TEE is higher than that of REE.

In the embodiments of the present application, an execution environment can be configured for the smart contract in the blockchain node according to predefined rules, and the execution environment meets the requirements of the smart contract for the security level of the execution environment. For example, in order to improve the security during the operation of the smart contract, a higher security execution environment (for example, REE) can be configured for the smart contracts in the blockchain nodes according to predefined rules.

As an example and not a limitation, the predefined rules may include: different types of smart contracts correspond to execution environments of different security levels. Under normal circumstances, different types of smart contracts have different requirements for the security level of the execution environment. For example, the security level of the execution environment of the financial-level smart contract is usually higher than that of the system-level smart contract. Requirements, the security level of the execution environment of the system-level smart contract is usually higher than the security level of the execution environment of the ordinary smart contract. In other words, if the security level of the execution environment configured for the financial-level smart contract is low, the execution environment may not be able to guarantee the security during the operation of the financial-level smart contract. Therefore, in order to improve the security during the operation of smart contracts, the security level of the execution environment that can be configured for financial-level smart contracts is higher than the security level of the execution environment configured for system-level smart contracts, which is the execution environment configured for system-level smart contracts The security level of is higher than the security level of the execution environment configured for ordinary smart contracts.

For example, TEE can be configured as the execution environment for system-level smart contracts, SEE as the execution environment for financial-level smart contracts, and REE as the execution environment for ordinary-level smart contracts. As an example and not a limitation, a system on chip (SoC) can be configured in the blockchain node, and the SoC can provide at least one of the execution environments of Trustzone, Bowmore, or SEE formed by eSE or inSE. The execution environment of Trustzone or Bowmore is called TEE, and the execution environment corresponding to eSE or inSE is called SEE. For example, when the blockchain node is a smart phone, the SoC can be configured in the smart phone, and the smart phone provides at least one of the execution environments of Trustzone, Bowmore, or SEE formed by eSE or inSE through the SoC. As an example and not a limitation, the foregoing SoC may support running an instruction set based on an advanced RISC machine (ARM) architecture, and an SoC that supports running an instruction set based on the ARM architecture is called an ARM-based SoC.

Figure 3 shows a simplified schematic diagram of the three-tier security architecture of REE+TEE+SEE, where REE is a rich execution environment, running security-insensitive programs and storing security-insensitive data, and there are certain security risks; TEE is trusted execution Environment, run security-sensitive programs and save security-sensitive data, provide a certain level of security isolation, SEE is a secure execution environment, run high security programs such as financial payments and save high security data such as financial payments, and provide a higher level of security isolation.

The aforementioned secure execution environment can be used as the SEE layer in the software system architecture in FIG. 3. The trusted execution environment and the general operating system software environment (such as the Android system environment) respectively serve as the TEE layer and the REE layer in the software system architecture in FIG. 3. There are two independent software systems between the trusted execution environment and the general operating system software, and there is security isolation, and the security isolation is very good. General operating system software and running programs of general application software based on the operating system cannot freely access the trusted execution environment. The trusted execution environment can exchange data with the secure execution environment. Therefore, there is security isolation between the general operating system software, the trusted execution environment, and the secure execution environment, so that the general operating system software or the running program of the common application software based on the software can access the trusted execution environment and the secure execution environment It is not arbitrary. Even if the access is executed, it needs to go through a specific software or hardware security interface, and the security isolation between the trusted execution environment and the safe execution environment is relatively low, and the operation is relatively convenient. The aforementioned ordinary application software may include various non-secure payment-related software, such as instant messaging software, games, office software, e-book software, or audio and video streaming media players.

In step 202, when the user 130 installs a smart contract for a certain blockchain node (for example, the blockchain node 1401) in the blockchain network 140, the blockchain node 1401 can be a smart contract according to the type of the smart contract. Contract configuration execution environment. For example, when the smart contract is a system-level smart contract, the blockchain node 1401 can configure TEE as the execution environment of the smart contract; or, when the smart contract is a financial-level smart contract, the blockchain node 1401 can configure the SEE as The execution environment of the smart contract.

In step 203, the blockchain node 1401 runs the smart contract in the execution environment configured for the smart contract. As an example and not a limitation, before the user 130 installs the smart contract for the blockchain node 1401 in the blockchain network 140, what the user 130 obtains from the management center 120 may be the binary file of the smart contract, that is, the smart contract provider 110 is in After the source code of the smart contract is written, the source code of the smart contract can be compiled to generate the binary file of the smart contract, and the binary file of the smart contract is provided to the management center 120, so that the user 130 can obtain it from the management center 120 Is the binary file of the smart contract. At this time, the blockchain node 1401 is running the binary file of the smart contract in the execution environment configured for the smart contract.

In the embodiment of the present application, in order to prevent the reverse leakage of the operation logic and data processing flow of the smart contract, the provider 110 of the smart contract may use the key pair negotiated with the blockchain network after generating the binary file of the smart contract. The binary file of the contract is encrypted. In this case, when the binary file of the smart contract is encrypted by the provider 110 of the smart contract, the blockchain node 1401 first needs to decrypt the binary file of the smart contract before running the binary file of the smart contract. The binary file of the smart contract obtained after running the decryption operation. At this time, the method 200 may further include: decrypting the smart contract in the execution environment.

In the embodiment of this application, in order to manage the complete life cycle of the smart contract, the complete life cycle of the smart contract includes deployment, storage, operation, and shutdown. The public key infrastructure (PKI) system is used to compare the smart contract. Carry out signature operations, verification operations, and revocation operations to realize the complete life cycle management of smart contracts.

As an example and not a limitation, in order to determine whether to run a smart contract, the provider 110 of the smart contract may perform a signature operation on the binary file of the smart contract after generating the binary file of the smart contract. In this case, when the binary file of the smart contract is signed by the provider 110 of the smart contract, the blockchain node 1401 first needs to check the binary file of the smart contract before deploying, storing and running the binary file of the smart contract. During the verification operation, the blockchain node 1401 will deploy, store and run the smart contract only when the blockchain node 1401 passes the verification of the smart contract that has been signed. At this time, the method 200 may further include: verifying and signing the smart contract in the execution environment.

It should be noted that the decryption operation and the verification operation of the above steps can be used together in specific implementation. For example, the provider 110 of the smart contract can encrypt the binary file of the smart contract. After the encryption operation is completed, the smart contract The provider 110 can sign the binary file of the encrypted smart contract. In this case, after the blockchain node 1401 passes the verification of the smart contract that has undergone the signature operation, before running the binary file of the smart contract, it first needs to decrypt the binary file of the smart contract that has passed the verification, and finally run The binary file of the smart contract obtained after the decryption operation.

In this embodiment of the application, in order to determine whether to stop running the smart contract, a device (for example, a server) for storing a certificate revocation list (CRL) can be deployed in the cloud to determine whether the smart contract has been revoked To manage. For example, when a certain smart contract has a problem or the latest version of the smart contract exists, the device can add the relevant information of the smart contract to the CRL, which means that the smart contract has been revoked.

Before running the smart contract, the blockchain node 1401 can determine whether the relevant information of the smart contract is stored in the CRL. If the relevant information of the smart contract is included in the CRL, the blockchain node 1401 will stop running the smart contract. At this point, the method 200 may further include: obtaining a CRL; determining whether to terminate the operation of the smart contract according to the CRL, and the CRL stores relevant information of the revoked smart contract; if the CRL includes the relevant information of the smart contract To terminate the operation of the smart contract.

For example, the CRL can be stored in the blockchain node 1401, and the blockchain node 1401 can obtain the CRL from the device storing the CRL by polling, and store the obtained CRL locally, or the blockchain node 1401 It can also receive the CRL sent by the device storing the CRL, and store the obtained CRL locally. For example, after the blockchain node 1401 obtains the CRL, it can store the CRL in a safer local storage area. For example, the storage area may include replay protected memory block (RPMB) and electrically programmable Fuse Efuse module or one-time programmable (OTP) memory. As an example and not limitation, the related information of the smart contract stored in the CRL may be the serial number and revocation time of the certificate of the smart contract, where the serial number of the certificate of the smart contract may be allocated by the management center 120 for the smart contract.

In the embodiment of the present application, the method 200 may further include: using homomorphic encryption technology or zero-knowledge proof technology to encrypt the private data generated in the blockchain. When encrypting the private data generated in the blockchain, homomorphic encryption technology or zero-knowledge proof technology can be used to encrypt the private data generated in the blockchain, and the private data generated in the blockchain can be encrypted. The private key used can be generated in the SEE environment.

In order to improve the performance of the encryption service, the operator (for example, the pairing operator) used when encrypting the private data generated in the blockchain can be hardened, that is, the operator can be passed through the hardware To achieve, thereby improving the performance of encryption services. In the embodiment of the present application, the program that calls the above-mentioned operator can be configured to run in an execution environment with higher security. For example, the program that calls the aforementioned operator can be configured to run in the TEE or SEE.

Above, the method for running a smart contract provided by the embodiment of the present application has been described in detail with reference to FIGS. 1 to 3. Hereinafter, the device for running a smart contract provided by an embodiment of the present application will be described in detail with reference to FIGS. 4 and 5.

4 is a schematic block diagram of a device 300 for running a smart contract provided by an embodiment of the application. The device 300 for running a smart contract can be applied to the blockchain network 140 and includes an acquisition module 301 and a processing module 302.

The obtaining module 301 is used to obtain a smart contract, which has a security level requirement.

The processing module 302 is configured to provide an execution environment for the smart contract to meet the requirements according to predefined rules.

The processing module 302 is also used to run the smart contract in the execution environment.

Optionally, the predefined rules include: different types of smart contracts correspond to execution environments of different security levels.

Optionally, the smart contract has undergone an encryption operation, and the processing module 302 is further configured to perform a decryption operation on the smart contract in the execution environment.

Optionally, the smart contract has undergone a signature operation, and the processing module 302 is further configured to perform a verification signature operation on the smart contract in the execution environment.

Optionally, the acquisition module 301 is also used to: obtain a certificate revocation list CRL, in which the relevant information of the smart contract that has been revoked is stored; the processing module 302 is also used to: terminate the operation of the smart contract according to the CRL contract.

Optionally, the related information of the smart contract includes the serial number and revocation time of the certificate of the smart contract that has been revoked.

Optionally, the CRL is stored in at least one of a replay protection memory block RPMB, an electrically programmable fuse Efuse module, or a one-time programmable OTP memory.

Optionally, the processing module 302 is further configured to use homomorphic encryption technology or zero-knowledge proof technology to encrypt the private data generated in the blockchain.

Exemplarily, the private key used when encrypting the private data generated in the blockchain may be generated in the execution environment provided by the SE.

Optionally, when using homomorphic encryption technology or zero-knowledge proof technology to encrypt the private data generated in the blockchain, the used operator is a hardened Pairing operator.

Optionally, the predefined rule includes at least one of the following: ordinary-level smart contracts correspond to rich execution environment REE; or, system-level smart contracts correspond to trusted execution environment TEE; or, financial-level smart contracts correspond to secure execution environment SEE.

It should be understood that the above-mentioned functions of the device 300 for running a smart contract in the embodiment of the present application can be implemented by an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof. The method of running a smart contract shown in FIG. 2 can also be implemented through software. When the method of running a smart contract shown in FIG. 2 is implemented through software, the device-side device 300 that runs the smart contract and its various modules may also be software modules.

The device 300 for running a smart contract according to an embodiment of the present application may correspond to the method described in the embodiment of the present application, and the above-mentioned and other operations and/or functions of each unit in the device 300 for running the smart contract are intended to realize the For the sake of brevity, the corresponding process executed by the blockchain node in the method shown here will not be repeated here.

FIG. 5 is a schematic block diagram of a device 400 for running a smart contract provided by an embodiment of the application. As shown in FIG. 5, the device 400 for running a smart contract includes a processor 401, a memory 402, a communication interface 403, and a bus 404. Among them, the processor 401, the memory 402, and the communication interface 403 communicate through the bus 404, and may also communicate through other means such as wireless transmission. The memory 402 is used to store instructions, and the processor 401 is used to execute instructions stored in the memory 402. The memory 402 stores program code 4021, and the processor 401 can call the program code 4021 stored in the memory 402 to execute the method for running a smart contract shown in FIG. 2.

It should be noted that in specific implementation, the processor 401 may be built into the SoC; or, the device 400 for running the smart contract includes the processor 401 and another independent SoC (not shown in the figure). When the processor 401 is located in the SoC, the device 400 running the smart contract provides at least one of the execution environments of Trustzone, Bowmore, or SEE formed by eSE or inSE through the SoC.

In a possible implementation manner, the processor 401 is configured to call the communication interface 403 to perform the following actions: obtain a smart contract, which has a security level requirement.

The processor 401 is further configured to configure an execution environment that meets the requirements for the smart contract according to predefined rules.

The processor 401 is also used to run the smart contract in the execution environment.

The processor 401 may include various types of processors, such as a CPU and a secure element (SE), where the CPU runs necessary software, for example, the CPU runs TEE software to form a Trustzone or Bowmore environment, and the SE runs necessary security software to form a SEE. The CPU can also run a general operating system, such as Android/Windows to form a REE. The processor 401 may also include other types of processors, such as a DSP, a microprocessor, or a microcontroller.

When the processor 401 includes a CPU and an SE, the CPU can obtain a smart contract, and the CPU configures an execution environment for the smart contract that meets its requirements according to the type of the smart contract.

For example, the smart contract is a financial-level smart contract, and the CPU can configure the SE environment for the financial-level smart contract, specifically the SEE corresponding to eSE or inSE, and the CPU can communicate with the SE to make the execution environment corresponding to the eSE or inSE Run this financial-level smart contract in

It should be noted that the above SE may have independent processors, memory, and storage units, where the SE and the above CPU may be integrated in one chip, or may also be integrated on different chips. The aforementioned CPU can be used to run general operating system software and communicate with the SE under the action of the aforementioned general operating system software.

Optionally, the smart contract has undergone an encryption operation, and the processor 401 is further configured to perform a decryption operation on the smart contract in the execution environment.

Optionally, the smart contract has undergone a signature operation, and the processor 401 is further configured to perform a verification signature operation on the smart contract in the execution environment.

Optionally, the processor 401 is further configured to call the communication interface 403 to perform the following actions: obtain a certificate revocation list CRL, in which the relevant information of the smart contract that has been revoked is stored; the processor 401 is also configured to: According to the CRL, the smart contract is terminated.

Optionally, the processor 401 is further configured to use homomorphic encryption technology or zero-knowledge proof technology to encrypt private data generated in the blockchain.

The memory 402 may include a read-only memory and a random access memory, and provides instructions and data to the processor 401. The memory 402 may also include non-volatile random access memory. The memory 402 may be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Among them, the non-volatile memory may be read-only memory (ROM), programmable read-only memory (ROM,

PROM), erasable programmable read-only memory (erasable PROM, EPROM), electrically erasable programmable read-only memory (electrically EPROM, EEPROM) or flash memory. The volatile memory may be random access memory (RAM), which is used as an external cache. By way of exemplary but not restrictive description, many forms of RAM are available, such as static random access memory (static RAM, SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (synchronous DRAM, SDRAM), Double data rate synchronous dynamic random access memory (double data date SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection dynamic random access memory (synchlink DRAM, SLDRAM) and direct Memory bus random access memory (direct rambus RAM, DR RAM).

In addition to the data bus, the bus 404 may also include a power bus, a control bus, and a status signal bus. However, for clear description, various buses are marked as the bus 404 in FIG. 5.

It should be understood that the device 400 for running a smart contract according to the embodiment of the present application may correspond to the device 300 for running a smart contract in the embodiment of the present application, and may correspond to the blockchain node in the method shown in FIG. 2 of the embodiment of the present application. When the device 400 for running a smart contract corresponds to the blockchain node in the method shown in FIG. 2, the various modules and other operations and/or functions of the device 400 for running a smart contract are designed to implement the routing in FIG. 2 The operation steps of the method executed by the block chain node are not repeated here for the sake of brevity.

It should be noted that the device for running smart contracts in the embodiments of this application may be a node device in a blockchain network, or, it may not be the device itself, but a component or module or chip in the device. This application does not deal with this. Specially limited. The foregoing embodiments can be implemented in whole or in part by software, hardware, firmware or any other combination. When implemented by software, the above-mentioned embodiments may be implemented in the form of a computer program product in whole or in part. The computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on the computer, the processes or functions described in the embodiments of the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center. Transmission to another website site, computer, server or data center via wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.). The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more sets of available media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium may be a solid state drive (SSD).

A person of ordinary skill in the art may be aware that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions run in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered beyond the scope of this application.

Those skilled in the art can clearly understand that, for the convenience and conciseness of description, the specific working process of the above-described system, device, and unit can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed system, device, and method may be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division, and there may be other divisions in actual implementation, for example, multiple units or components can be combined or It can be integrated into another system, or some features can be ignored or not run. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.

In addition, the functional units in each embodiment of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units may be integrated into one unit.

If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on this understanding, the technical solution of this application essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) run all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code .

The above are only specific implementations of this application, but the protection scope of this application is not limited to this. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application. Should be covered within the scope of protection of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

A device for running smart contracts, characterized in that the device is applied to a blockchain network and includes:

The obtaining module is used to obtain a smart contract, which has a security level requirement;

A processing module, configured to configure an execution environment for the smart contract that meets the requirements according to predefined rules;

The processing module is also used to run the smart contract in the execution environment.
The device according to claim 1, wherein the predefined rules comprise: different types of smart contracts correspond to execution environments of different security levels.
The device according to claim 1 or 2, wherein the smart contract has undergone an encryption operation, and the processing module is further configured to: perform a decryption operation on the smart contract in the execution environment.
The device according to any one of claims 1 to 3, wherein the smart contract has undergone a signature operation, and the processing module is further configured to: verify and sign the smart contract in the execution environment operating.
The device according to any one of claims 1 to 4, wherein the obtaining module is further configured to: obtain a certificate revocation list CRL, in which information related to the smart contract that has been revoked is stored in the CRL ；

The processing module is also used to terminate the operation of the smart contract according to the CRL.
The device according to claim 5, wherein the related information of the smart contract includes the serial number and revocation time of the certificate of the smart contract that has been revoked.
The device according to claim 5 or 6, wherein the CRL is stored in at least one of a replay protection memory block RPMB, an electrically programmable fuse Efuse module, or a one-time programmable OTP memory.
The device according to any one of claims 1 to 7, wherein the processing module is further configured to use homomorphic encryption technology or zero-knowledge proof technology to encrypt private data generated in the blockchain.
The device according to any one of claims 2 to 8, wherein the predefined rule comprises at least one of the following:

Ordinary smart contract corresponds to the rich execution environment REE; or,

The system-level smart contract corresponds to the trusted execution environment TEE; or,

Financial-level smart contracts correspond to the secure execution environment SEE.
A method for running a smart contract, characterized in that the method is executed by any blockchain node in the blockchain network, and includes:

Obtain a smart contract, which has a security level requirement;

According to predefined rules, configure an execution environment that meets the requirements for the smart contract;

Run the smart contract in the execution environment.
The method according to claim 10, wherein the predefined rules comprise: different types of smart contracts correspond to execution environments of different security levels.
The method according to claim 10 or 11, wherein the smart contract has undergone an encryption operation, and the method further comprises:

Before running the smart contract in the execution environment, decrypt the smart contract in the execution environment.
The method according to any one of claims 10 to 12, wherein the smart contract has undergone a signature operation, and the method further comprises:

Before running the smart contract in the execution environment, verify and sign the smart contract in the execution environment.
The method according to any one of claims 10 to 13, wherein the method further comprises:

Obtain a certificate revocation list CRL, in which the relevant information of the smart contract that has been revoked is stored;

According to the CRL, terminate the operation of the smart contract.
The method according to claim 14, wherein the related information of the smart contract includes the serial number and revocation time of the certificate of the smart contract that has been revoked.
The method according to claim 14 or 15, wherein the CRL is stored in at least one of a replay protection memory block RPMB, an electrically programmable fuse Efuse module, or a one-time programmable OTP memory.
The method according to any one of claims 10 to 16, wherein the method further comprises:

Use homomorphic encryption technology or zero-knowledge proof technology to encrypt the private data generated in the blockchain.
The method according to any one of claims 11 to 17, wherein the predefined rule comprises at least one of the following:

Ordinary smart contract corresponds to the rich execution environment REE; or,

The system-level smart contract corresponds to the trusted execution environment TEE; or,

Financial-level smart contracts correspond to the secure execution environment SEE.