WO2023273994A1

WO2023273994A1 - Method, system, and apparatus for executing smart contract, and storage medium

Info

Publication number: WO2023273994A1
Application number: PCT/CN2022/100522
Authority: WO
Inventors: 林志平
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2021-07-01
Filing date: 2022-06-22
Publication date: 2023-01-05
Also published as: CN113256296B; CN113256296A

Abstract

Disclosed in embodiments of the present description are a method, system, and apparatus for executing a smart contract, and a storage medium. The method comprises a node flow implemented by a blockchain node process running in a host environment, and a contract flow implemented by a process running in a secure container. The secure container is a container not sharing the kernel with the host environment. The node flow comprises: receiving a blockchain transaction; in response to receiving the blockchain transaction, creating the process in the secure container to execute native execution code of a smart contract called by the blockchain transaction, the format of the native execution code corresponding to high-level language to which source code of the smart contract belongs; and obtaining an execution result of the blockchain transaction. The contract process comprises: executing the native execution code of the smart contract in the secure container.

Description

Method, system, device and storage medium for smart contract execution

technical field

This specification relates to the field of information technology, and in particular to a method, system, device and storage medium for executing smart contracts.

Background technique

The development of smart contracts (referred to as contracts) is an important part of blockchain development. At present, most chains in the blockchain industry compile contract source codes written in high-level languages into low-end bytecodes, and then compile them in low-end bytecodes. Run the smart contract in a virtual machine that matches the code (that is, execute the low-end bytecode).

However, the types of high-level languages that support the conversion of low-end bytecodes are limited, that is, the types of high-level languages that can be selected when using the above-mentioned contract execution methods are limited, and cannot meet the needs of various high-level language developers to develop smart contracts.

Contents of the invention

One of the embodiments of this specification provides a smart contract execution method. The method includes a node process implemented by a blockchain node process running in a host environment, and a contract process implemented by a process running in a secure container, and the secure container is a container that does not share a kernel with the host environment . Wherein, the node process includes: receiving a blockchain transaction; in response to receiving the blockchain transaction, creating a process in the secure container to execute the native execution code of the smart contract called by the blockchain transaction, so The format of the native execution code corresponds to the high-level language to which the source code of the smart contract belongs; and the execution result of the blockchain transaction is obtained. The contract process includes: executing the native execution code of the smart contract in the secure container.

One of the embodiments of this specification provides a smart contract execution system. The system includes a blockchain node process running in a host environment and a process running in a secure container, and the secure container is a container that does not share a kernel with the host environment. Wherein, the block chain node process is used to: receive the block chain transaction, in response to receiving the block chain transaction, create a process in the security container, to execute the native function of the smart contract called by the block chain transaction execution code, the native execution code corresponds to the high-level language to which the source code of the smart contract belongs; and the execution result of the blockchain transaction is obtained. The process in the secure container is used for: executing the native execution code of the smart contract in the secure container.

One of the embodiments of this specification provides a smart contract execution device. The apparatus includes a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the smart contract execution method described in any embodiment of this specification is implemented.

One of the embodiments of this specification provides a computer storage medium, the storage medium stores instructions, and when the processor executes the instructions, the smart contract execution method as described in any embodiment of this specification is implemented.

Description of drawings

This specification will be further illustrated by way of exemplary embodiments, which will be described in detail with the accompanying drawings. These examples are non-limiting, and in these examples, the same number indicates the same structure, wherein:

FIG. 1 is a schematic flowchart of a smart contract execution method according to some embodiments of this specification;

Fig. 2 is an interactive schematic diagram of a smart contract execution method according to some embodiments of this specification.

detailed description

In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the following briefly introduces the drawings that need to be used in the description of the embodiments. Apparently, the accompanying drawings in the following description are only some examples or embodiments of this specification, and those skilled in the art can also apply this specification to other similar scenarios. Unless otherwise apparent from context or otherwise indicated, like reference numerals in the figures represent like structures or operations.

It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, components, parts or assemblies of different levels. However, the words may be replaced by other expressions if other words can achieve the same purpose.

As indicated in this specification, words such as "a", "an", "an" and/or "the" are not specific to the singular and may include the plural unless the context clearly indicates an exception. Generally speaking, the terms "comprising" and "comprising" only suggest the inclusion of clearly identified steps and elements, and these steps and elements do not constitute an exclusive list, and the method or device may also contain other steps or elements.

The flowchart is used in this specification to illustrate the operations performed by the system according to the embodiment of this specification. It should be understood that the preceding or following operations are not necessarily performed in the exact order. Instead, various steps may be processed in reverse order or simultaneously. At the same time, other operations can be added to these procedures, or a certain step or steps can be removed from these procedures.

First, some basic concepts involved in this manual are introduced.

Blockchain transactions (referred to as transactions) can be used to record various events and/or data. In some embodiments, the events recorded in the transaction may include one or more of the joining of a new node, the exit of a node, the transfer, and the like. In some embodiments, the data of transaction records may include one or more of medical information, electronic contracts, electronic credentials, electronic orders, digital fingerprints, and the like.

The expected code can be triggered by the transaction, which can also be called the execution of the transaction, and the blockchain node can be the executor of the transaction. As an example only, the transaction used to record the transfer behavior can trigger the update of the account balance of both parties to the transfer; Chain data query, etc.

In some embodiments, execution of a transaction may include invocation of a smart contract. A smart contract (referred to as a contract) can refer to a digital agreement that is distributed and stored in each node in the blockchain system and can be automatically executed under certain conditions. The essence of a smart contract is a piece of code running in the blockchain network to complete the business logic assigned by the user.

With the continuous development of the blockchain, its application scenarios continue to expand, and more and more developers join the development of the blockchain. In blockchain development, smart contract development is very important. At present, most chains in the blockchain industry compile the contract source code written in a high-level language into low-end bytecode, and then run the smart contract in a virtual machine that matches the low-end bytecode (that is, execute the low-end bytecode). code). For example, Ethereum contract developers usually choose to write contract source code in Solidity language. Correspondingly, after compiling the contract source code written in Solidity language into evm format bytecode (referred to as evm bytecode), the evm bytecode can be executed in the EVM virtual machine. For another example, most contract developers of EOS (Enterprise Operating System) choose to write contract source code in C++ language. Correspondingly, after compiling the contract source code written in C++ language into wasm format bytecode (wasm bytecode for short), the wasm bytecode can be executed in the WASM (Web Assembly) virtual machine.

Some features of the virtual machine can guarantee contract security to a certain extent (such as filtering unsafe statements in the code). Contract security includes but is not limited to not allowing the contract to obtain unauthorized data, such as accessing local disk files, accessing network resources, etc. And/or do not allow contract behaviors to damage the security of the host environment (operating system), such as not allowing smart contracts to obtain some call permissions that affect the normal operation of the operating system (such as fork, kill, chmod, ptrace, etc.). However, the types of high-level languages that support conversion into low-end bytecodes are limited, so that the types of high-level languages available for the above-mentioned contract execution methods are limited, and cannot meet the needs of various high-level language developers to develop smart contracts.

Although there are also blockchain architectures (such as Fabric) that support the execution of smart contracts in a native execution mode, they do not restrict the operation authority of the contract to ensure contract security. For example, some alliance chain architectures only rely on the addition of authorized members to ensure contract security. . In the absence of restrictions on the operation authority of the contract, if there are some security vulnerabilities, and at the same time there are "evil" smart contracts that take advantage of the security vulnerabilities, it is likely to lead to the leakage of private data, unreliable operation of nodes and other issues.

It should be noted that the native execution mode is also called traditional/conventional execution mode, which refers to compiling source code written in a high-level language into native execution code (different from low-end bytecode) for execution. For example, for the Java language, the native execution mode refers to compiling the source code written in the Java language into a bytecode in a class format for execution. As another example, for the C++ language, the native execution method refers to compiling the source code written in the C++ language into a bytecode that matches the target CPU architecture. It can be understood that the target CPU architecture here specifically refers to the CPU architecture used to execute the contract. Each high-level language corresponds to a native executable code, and a limited variety of high-level languages support the conversion of source code into low-level bytecodes in a uniform format. The smart contract code executed according to the native execution method (native smart contract for short) can meet the needs of various high-level language developers to develop smart contracts. In addition, native executable code is more debuggable than low-end bytecode.

In some embodiments, in order to support the execution of native smart contracts, the container can be used as the execution environment of native smart contracts. Containers have the advantages of less resources, fast deployment, easy portability, and isolation. The contract execution of each transaction can establish a one-to-one correspondence with the container instance. It can be understood that the container instance refers to a specific single container. In this way, the isolation of the container can be used to isolate the contract execution of different transactions.

However, ordinary containers (such as the Docker container (Docker for short) developed by Docker, Inc.) share the kernel (kernel) with the host environment (operating system), and "evil" smart contracts can use kernel vulnerabilities to attack the host environment, steal private data or even corrupt the operating system. It should be noted that the kernel is the core of the operating system (Operation System, OS), which is responsible for managing the processes, memory, device drivers, files and network systems of the operating system, and determines the performance and stability of the operating system.

In view of this, the embodiment of this specification provides a method and system for executing native smart contracts through a secure container, which can meet the needs of developers of various languages for developing smart contracts, ensure high code debuggability, and ensure the integrity of smart contracts. safety.

It can be understood that, different from ordinary containers (such as Docker), a secure container refers to a container that does not share a kernel with the host environment. As an example only, the security container may include one or more of the kata container developed by the open source community (see https://katacontainers.io/ for specific information), the gVisor container developed by Google, the Firecracker developed by Amazon, etc. .

Fig. 1 is a schematic flowchart of a method for executing a smart contract according to some embodiments of this specification.

The method may include a node process implemented by a blockchain node process running in a host environment, and a contract process implemented by a process running in a secure container. Wherein, the blockchain node process may refer to a running blockchain program. In some embodiments, the host environment and the security container can be integrated on a single device (host machine), or distributed on multiple devices, for example, the security container can be run on a cloud server. In some embodiments, a communication connection can be established between the host environment and the secure container through a network module of the host environment itself.

As shown in Figure 1, the node process may include: receiving a transaction; in response to receiving the transaction, creating a process in a secure container to execute the native execution code of the smart contract called by the transaction; obtaining the execution result of the transaction (Also known as a "receipt"). The contract process may include executing the native execution code of the smart contract in a secure container.

It can be understood that multiple processes can be run in the blockchain node process/secure container to realize the corresponding process.

In some embodiments, in response to receiving a transaction, the blockchain node process may first create a secure container for contract execution, and then create a daemon process in the secure container. Optionally, the blockchain node process can also create a daemon process in the created secure container. Optionally, the blockchain node process can also directly use the created daemon process. The daemon process can be used to manage the life cycle of the contract execution process, including being responsible for the creation, destruction, and invocation of the contract execution process. Furthermore, the daemon process can create a contract execution process in the secure container, obtain the native execution code of the smart contract called by the transaction from the blockchain node process, and pass the native execution code to the contract execution process. Among them, the contract execution process can be used to execute the native execution code of the smart contract called by the transaction. In some embodiments, contract execution may include setting the value of a variable in the smart contract. Specifically, the contract execution process can obtain the value of the variable in the smart contract from the block chain node process, set the value of the variable, and return the set value of the variable to the block chain node process, In order to enable the blockchain node process to obtain the execution result of the transaction. Among them, the name (key) of the variable to be set can be specified in the transaction, and the blockchain node process can query the value (value) of the variable according to the name of the variable. It can be understood that the key and value of the same variable can be stored in the form of key-value pairs for easy query.

It can be understood that certain features, structures or characteristics in one or more embodiments of this specification can be properly combined. An example is given below in conjunction with FIG. 2 .

As shown in Figure 2, the blockchain node program process may include a container interface, a database (DB), a container management module and a gRPC client, and the daemon process may include a gRPC server and a contract running module. Among them, the container interface can be used to receive transactions. The container management module may be configured to, in response to the container interface receiving a transaction, create a secure container and create a process in the secure container to execute the native execution code of the smart contract invoked by the transaction. Databases can be used to store blockchain data. Blockchain data includes one or more of block data, account status, account storage, contract code (such as native execution code), etc.

The gRPC server can communicate with the gRPC client as a communication module for communicating with the blockchain node process, and the communication can include obtaining the native execution code of the smart contract. Optionally, the gRPC client can actively communicate with the gRPC server. Specifically, in response to the container interface receiving the transaction, the gRPC client can obtain the native execution code of the smart contract invoked by the transaction from the database through the container interface, and send it to the gRPC server.

The contract running module obtains the native execution code of the called smart contract from the gRPC server and passes it to the contract execution process.

Thus, the contract execution process can execute the obtained native execution code.

In some embodiments, a container proxy can be set between the container interface and the gRPC client, and the container interface can communicate with the daemon process through the container proxy and the gRPC client after receiving the transaction.

In some embodiments, the communication between the contract execution process and the blockchain node process can also follow the client-server model. That is, the gRPC client in the contract execution process can initiate a request to the gRPC server thread pool (thread collection, thread is a thread) in the blockchain node process, and the gRPC server thread pool responds to the request of the contract execution process accordingly. Specifically, the request may include obtaining the value of the contract variable to be set, setting the value of the contract variable, and notifying the contract execution result.

The gRPC server thread pool can return the execution contract to the contract execution process (gRPC client in it) through the VM (Virtual Machine, virtual machine) thread (such as VM thread1, VM thread2, etc.) and Container (container, such as Container1, Container2, etc.) The required data, such as the value of the contract variable to be set. The IO thread/Container in the gRPC server thread pool can access messages through the queue. For example, the IO thread can put the message into the queue through the Msg Put function (operation), and the Container can take the message out of the queue through the Msg Get function (operation), and then put the obtained response data into the queue through the Return function (operation) For the IO thread to take out.

Each thread (IO thread/VM thread) can be responsible for the execution of one transaction at a time. The contract execution process notifies the threads in the gRPC server thread pool that after the execution of the native smart contract invoked by a certain transaction is completed, the VM thread responsible for the execution of the transaction can confirm that the transaction has been executed. Correspondingly, the container interface can obtain the execution result of the transaction (ie, the receipt).

It should be noted that, the above descriptions about the process are only for illustration and description, and do not limit the scope of application of this specification. For those skilled in the art, various modifications and changes can be made to the flow under the guidance of this specification. However, such modifications and changes are still within the scope of this specification.

Referring to FIG. 2 , the embodiment of this specification also provides a smart contract execution system, which may include a blockchain node process running in a host environment and a process running in a secure container.

Wherein, the blockchain node process can be used to: receive blockchain transactions, start a process in the secure container according to the received blockchain transactions, to execute the native execution code of the smart contract invoked by the blockchain transactions , the native execution code corresponds to the high-level language to which the source code of the smart contract belongs; and the execution result of the blockchain transaction is obtained.

The process in the secure container is used for: executing the native execution code of the smart contract in the secure container.

It should be understood that the above smart contract execution system and its modules can be implemented in various ways. For example, in some embodiments, the system and its modules may be implemented by hardware, software, or a combination of software and hardware. Wherein, the hardware part can be implemented by using dedicated logic; the software part can be stored in a memory and executed by an appropriate instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above can be implemented using computer-executable instructions and/or contained in processor control code, for example on a carrier medium such as a magnetic disk, CD or DVD-ROM, such as a read-only memory (firmware ) or on a data carrier such as an optical or electronic signal carrier. The system and its modules in this specification can not only be realized by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, etc., or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc. , can also be realized by software executed by various types of processors, for example, and can also be realized by a combination of the above-mentioned hardware circuits and software (for example, firmware).

It should be noted that the above description of the system and its modules is only for convenience of description, and does not limit this description to the scope of the illustrated embodiments. It can be understood that for those skilled in the art, after understanding the principle of the system, it is possible to combine various modules arbitrarily, or form a subsystem to connect with other modules without departing from this principle. For example, in some embodiments, as shown in FIG. 2 , multiple processes with different divisions of labor can be run in the secure container to jointly implement the contract process. Such deformations are within the protection scope of this specification.

The possible beneficial effects of the embodiments of this specification include but are not limited to: (1) The container is used as the execution environment of the native smart contract to support the execution of the native smart contract, and the execution of the smart contract in a native way can satisfy various language developers The requirements of smart contracts ensure high code debuggability and ensure the security of smart contracts; (2) introduce a security container that does not share the kernel with the host environment to ensure contract security and prevent "evil" smart contracts from passing through kernel vulnerabilities Attack the host environment and protect the data security of the host environment. It should be noted that different embodiments may have different beneficial effects. In different embodiments, the possible beneficial effects may be any one or a combination of the above, or any other possible beneficial effects.

The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only an example, and does not constitute a limitation to the embodiment of this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements and amendments to the embodiments of this specification. Such modifications, improvements and corrections are suggested in the embodiments of this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

Meanwhile, this specification uses specific words to describe the embodiments of this specification. For example, "one embodiment", "an embodiment", and/or "some embodiments" refer to a certain feature, structure or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that two or more references to "an embodiment" or "an embodiment" or "an alternative embodiment" in different places in this specification do not necessarily refer to the same embodiment .

In addition, those skilled in the art will understand that all aspects of the embodiments of this specification can be illustrated and described by several patentable categories or situations, including any new and useful process, machine, product or combination of substances, or Any new and useful improvements to them. Correspondingly, various aspects of the embodiments of this specification may be completely executed by hardware, may be completely executed by software (including firmware, resident software, microcode, etc.), or may be executed by a combination of hardware and software. The above hardware or software may be referred to as "block", "module", "engine", "unit", "component" or "system". In addition, aspects of the embodiments of this specification may be embodied as a computer product on one or more computer-readable media, the product including computer-readable program code.

A computer storage medium may contain a propagated data signal embodying a computer program code, for example, in baseband or as part of a carrier wave. The propagated signal may have various manifestations, including electromagnetic form, optical form, etc., or a suitable combination. A computer storage medium may be any computer-readable medium, other than a computer-readable storage medium, that can be used to communicate, propagate, or transfer a program for use by being coupled to an instruction execution system, apparatus, or device. Program code residing on a computer storage medium may be transmitted over any suitable medium, including radio, electrical cable, fiber optic cable, RF, or the like, or combinations of any of the foregoing.

The computer program codes required for the operation of each part of the embodiments of this specification can be written in any one or more programming languages, including object-oriented programming languages such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C++, C#, VB.NET , Python, etc., conventional programming languages such as C language, VisualBasic, Fortran2003, Perl, COBOL2002, PHP, ABAP, dynamic programming languages such as Python, Ruby and Groovy, or other programming languages. The program code may run entirely on the user's computer, or as a stand-alone software package, or run partly on the user's computer and partly on a remote computer, or entirely on the remote computer or processing device. In the latter case, the remote computer can be connected to the user computer through any form of network, such as a local area network (LAN) or wide area network (WAN), or to an external computer (such as through the Internet), or in a cloud computing environment, or as a service Use software as a service (SaaS).

In addition, unless clearly stated in the claims, the sequence of processing elements and sequences, the use of numbers and letters, or the use of other names in the embodiments of this specification are not used to limit the sequence of the processes and methods of the embodiments of this specification. While the foregoing disclosure has discussed by way of various examples some embodiments of the invention that are presently believed to be useful, it should be understood that such detail is for illustrative purposes only and that the appended claims are not limited to the disclosed embodiments, but rather, the claims The claims are intended to cover all modifications and equivalent combinations that fall within the spirit and scope of the embodiments of this specification. For example, while the system components described above may be implemented as hardware devices, they may also be implemented as a software-only solution, such as installing the described system on an existing processing device or mobile device.

Similarly, it should be noted that, in order to simplify the description of the disclosure of the embodiments of this specification, so as to facilitate the understanding of one or more embodiments of the invention, in the foregoing descriptions of the embodiments of this specification, sometimes multiple features are combined into one implementation examples, drawings or descriptions thereof. However, this method of disclosure does not imply that the embodiments of the present specification require more features than those recited in the claims. Indeed, embodiment features are less than all features of a single foregoing disclosed embodiment.

Each patent, patent application, patent application publication, and other material, such as article, book, specification, publication, document, etc., cited in this specification is hereby incorporated by reference in its entirety. Application history documents that are inconsistent with or conflict with the content of this specification are excluded, and documents (currently or later appended to this specification) that limit the broadest scope of the claims of this specification are excluded. It should be noted that if there is any inconsistency or conflict between the descriptions, definitions, and/or terms used in the accompanying materials of this manual and the contents of this manual, the descriptions, definitions and/or terms used in this manual shall prevail .

Finally, it should be understood that the embodiments described in this specification are only used to illustrate the principles of the embodiments of this specification. Other modifications may also fall within the scope of the embodiments of this specification. Therefore, by way of example and not limitation, alternative configurations of the embodiments of this specification may be considered consistent with the teachings of this specification. Accordingly, the embodiments of this specification are not limited to the embodiments explicitly introduced and described in this specification.

Claims

A smart contract execution method, wherein the method includes a node process implemented by a block chain node process running in a host environment, and a contract process implemented by a process running in a secure container, and the secure container is connected to said host environment does not share a kernel container;

Wherein, the node process includes: receiving a blockchain transaction; in response to receiving the blockchain transaction, creating a process in the secure container to execute the native execution code of the smart contract called by the blockchain transaction, so The format of the native execution code corresponds to the high-level language to which the source code of the smart contract belongs; the execution result of the blockchain transaction is obtained;

The contract process includes: executing the native execution code of the smart contract in the secure container.
The method of claim 1, wherein said creating a process in said secure container in response to receiving a blockchain transaction comprises:

In response to receiving a blockchain transaction, create a daemon process in the secure container; the daemon process is used to: create a contract execution process for executing the native execution code of the smart contract in the secure container, from The block chain node process obtains the native execution code of the smart contract, and transmits the native execution code to the contract execution process.
The method according to claim 2, wherein the daemon process includes a communication module and a contract running module; wherein the communication module is used to communicate with the block chain node process, and the communication includes obtaining the intelligent The native execution code of the contract; the contract running module is used to obtain the native execution code of the smart contract from the communication module, and deliver it to the contract execution process.
The method according to claim 2, wherein said executing the native execution code of said smart contract comprises:

Obtain the value of the variable in the smart contract from the block chain node process, set the value of the variable, and return the set value of the variable to the block chain node process, so that the block The block chain node process obtains the execution result of the block chain transaction.
The method according to claim 1, wherein the block chain node process includes a container interface for receiving block chain transactions, the block chain node process also includes a container management module, and the container management module is used for : In response to the container interface receiving a blockchain transaction, creating a secure container and creating a process in the secure container to execute the native execution code of the smart contract invoked by the blockchain transaction.
The method according to claim 2, wherein the block chain node process includes a container interface, a database, a container management module and a gRPC client; the daemon process includes a gRPC server and a contract running module;

Wherein, the container interface is used to receive blockchain transactions; the database is used to store blockchain data, and the blockchain data includes native execution codes of smart contracts; the container management module is used to respond to the The container interface receives the blockchain transaction, creates the secure container and creates the daemon process in the secure container to execute the native execution code of the smart contract called by the blockchain transaction; the gRPC client uses Responding to receiving a blockchain transaction in response to the container interface, obtaining the native execution code of the smart contract invoked by the blockchain transaction from the database through the container interface, and sending it to the gRPC server;

The contract running module is used to obtain the native execution code of the called smart contract from the gRPC server and deliver it to the contract execution process.
The method according to claim 1, wherein the secure container comprises one or more of a kata container, a gVisor container, and a Firecracker container.
A smart contract execution system, wherein the system includes a blockchain node process running in a host environment and a process running in a secure container, the secure container is a container that does not share a kernel with the host environment;

Wherein, the block chain node process is used to: receive block chain transactions; in response to receiving block chain transactions, create a process in the security container to execute the native execution code, the native execution code corresponds to the high-level language to which the source code of the smart contract belongs; obtain the execution result of the blockchain transaction;

The process in the secure container is used for: executing the native execution code of the smart contract in the secure container.
A smart contract execution device, including a processor and a storage device, the storage device is used to store instructions, and when the processor executes the instructions, the method according to any one of claims 1-7 is implemented.
A computer storage medium, wherein the storage medium stores instructions, and when the processor executes the instructions, the method according to any one of claims 1-7 is implemented.