WO2024103689A1 - State change method and apparatus, device, and nonvolatile readable storage medium - Google Patents

Abstract

The present application discloses a state change method and apparatus, a device, and a nonvolatile readable storage medium. The method comprises: acquiring a state change request initiated by any smart contract participant; according to different levels of changed objects involved in the state change request, triggering state machine managers of corresponding levels to call state machines of the corresponding levels, so as to detect current states of the changed objects, wherein the levels of the changed objects comprise a smart contract layer or a functional function layer inside a smart contract, and the state machine managers and the state machines corresponding to the changed objects of different levels are different; and if the current states of the changed objects meet a change condition, triggering the state machine managers of the corresponding levels to call the state machines of the corresponding levels, so as to change the states of the changed objects according to the state change request. Therefore, in the present application, multi-level life cycle management is designed to perform vulnerability protection on a smart contract, thereby ensuring the stability of a blockchain system.

Description

State changing method, device, equipment and non-volatile readable storage medium

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to the Chinese patent application filed with the China Patent Office on November 14, 2022, with application number 202211417421.5, and application name “A state changing method, device, equipment and storage medium”, all contents of which are incorporated by reference in this application.

Technical Field

The present application relates to the field of blockchain technology, and in particular to a state change method, device, equipment and non-volatile readable storage medium.

Background technique

Blockchain application scenarios are becoming more and more abundant, and many blockchain business implementations are completed by writing smart contracts. Smart contracts in blockchain control all data and assets on the chain, making them easy targets for hackers. The open and transparent nature of blockchain also makes smart contracts transparent, greatly reducing the cost of attacks. At the same time, once a smart contract is deployed on the chain, it cannot be changed, and the running process is not subject to any interference. Once a vulnerability in the contract is triggered, it is difficult to repair. In the process of writing smart contracts, design defects in the programming language itself and developers' understanding of the programming language will lead to vulnerabilities in the developed smart contracts. In the process of executing smart contracts, the security of the execution environment and the data required for execution will also affect the execution results. Therefore, the sources of smart contract security threats can be divided into unsafe contract programming and unreliable contract execution. However, the current life cycle management of smart contracts is not perfect, which makes the smart contract vulnerability protection ability weak.

Therefore, the above technical problems need to be solved by those skilled in the art urgently.

Summary of the invention

In view of this, the purpose of this application is to provide a state change method, device, equipment and non-volatile readable storage medium, design multi-level life cycle management to protect smart contracts from vulnerabilities, and ensure the stability of the blockchain system. The solution is as follows:

This application provides a state change method, including:

Get state change requests initiated by any smart contract participant;

According to the different levels of the changed objects in the state change request, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to detect the current state of the changed object; wherein the level of the changed object includes the smart contract layer or the function layer inside the smart contract, and the state machine managers and state machines corresponding to the changed objects of different levels are different;

If the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request.

Optionally, according to the different levels of the changed object of the state change request, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to detect the current state of the changed object, including:

If the level of the change object of the state change request is the smart contract layer, trigger the first state machine manager to call the first state machine to obtain the current first state machine state corresponding to the smart contract;

Determine whether the current state of the first state machine meets the change condition;

Correspondingly, if the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request, including:

Trigger the first state machine manager to call the first state machine to change the state of the smart contract according to the state change request.

Optionally, triggering the first state machine manager to call the first state machine to change the state of the smart contract according to the state change request includes:

In a case where the state change request is configured to request the smart contract layer to change the state of the first state machine from a deployed state to an executed state, detecting whether the smart contract is in a deployed state or a stopped state;

When the smart contract is in a deployed state or a stopped state, the state machine of the smart contract is changed to an execution state, wherein the first state machine state includes a deployed state and an execution state.

Optionally, determining whether the current state of the first state machine satisfies a change condition includes:

It is determined whether the current first state machine state is a pre-state of the changed state required by the state change request, and if so, it is determined that the current first state machine state meets the change condition.

Optionally, according to the different levels of the changed object of the state change request, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to detect the current state of the changed object, including:

If the level of the change object of the state change request is the function layer inside the smart contract, the first state machine manager is triggered to call the first state machine to obtain the current first state machine state corresponding to the smart contract, and the second state machine manager is triggered to call the second state machine to obtain the current second state machine state corresponding to the function;

Determine whether the current first state machine state and the current second state machine state both meet the change condition;

Correspondingly, if the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request, including:

The second state machine manager is triggered to call the second state machine to change the state of the functional function according to the state change request.

Optionally, triggering the second state machine manager to call the second state machine to change the state of the function according to the state change request includes:

In the case where the state change request is used to request the function layer to perform a stop state operation, detecting whether the smart contract is in the execution state, and detecting whether the function layer is in the execution state;

When the smart contract is in the execution state and the functional function layer is in the execution state, the second state machine state is changed to the stop state, and the second state machine state includes the execution state and the stop state.

Optionally, determining whether both the current first state machine state and the current second state machine state satisfy the change condition includes:

It is determined whether the current second state machine state satisfies the hierarchical constraint condition of the first state machine state. If so, it is determined that both the first state machine state and the second state machine state satisfy the change condition.

Determining whether the current second state machine state satisfies the hierarchical constraint condition of the first state machine state includes:

Matching the second state machine state with the first state machine state, wherein the first state machine state includes a deployment state, an execution state, a stop state, an upgrade state, and a destruction state, and the second state machine state includes a deployment state, an execution state, a stop state, and an upgrade state;

When the second state machine state matches the first state machine state, it is determined that the second state machine state satisfies the hierarchical constraint condition of the first state machine state.

Optionally, after determining whether the current second state machine state satisfies the hierarchical constraint condition of the first state machine state, the method further includes:

It is determined whether the current second state machine state is a pre-state of the changed state required by the state change request. If so, it is determined that both the first state machine state and the second state machine state meet the change condition.

Optionally, obtain state change requests initiated by any smart contract participant, including:

Obtain the state change request initiated by any smart contract participant and the threshold signature of the state change request; wherein the threshold signature is obtained by the smart contract participant signing the state change request by means of the threshold signature;

Accordingly, before checking the current state of the changed object, the following steps are also included:

According to the different levels of the changed object of the state change request, the state machine manager of the corresponding level is triggered to verify the threshold signature based on the state change request. If the verification passes, the step of detecting the current state of the changed object is executed.

Optionally, according to the different levels of the change object of the state change request, the state machine manager of the corresponding level is triggered to verify the threshold signature based on the state change request, including:

If the level of the change object of the state change request is the smart contract layer, the first state machine manager is triggered to verify the threshold signature based on the state change request.

Optionally, according to the different levels of the change object of the state change request, the state machine manager of the corresponding level is triggered to verify the threshold signature based on the state change request, including:

If the level of the change object of the state change request is the function layer inside the smart contract, the second state machine manager is triggered to verify the threshold signature based on the state change request.

Optionally, the state change method also includes:

Each smart contract participant performs a hash operation on the state change request to obtain a first hash result, and signs the hash result to obtain a corresponding signature share, and uses a threshold signature to restore a base signature share based on each signature share;

Each smart contract participant calculates the base signature parameters based on the base private key share, temporary private key share and temporary public key share, and obtains a threshold signature containing the base signature parameters and the base signature share.

Optionally, the state change method also includes:

The key generation center generates the base private key and the corresponding base private key share through the threshold secret sharing algorithm, and allocates and issues different base private key shares to different smart contract participants according to target requirements;

Each smart contract participant generates multiple temporary private key shares and multiple temporary public key shares and sends the multiple temporary private key shares and multiple temporary public key shares to other smart contract participants, and receives the temporary private key shares and temporary public key shares sent by other smart contract participants;

Each smart contract participant calculates a temporary private key share based on its own temporary private key share and the temporary private key share it receives, and calculates a temporary public key share based on its own temporary public key share and the temporary public key share it receives;

Each smart contract participant calculates the base signature parameters based on the temporary public key sharing share.

Optionally, different base private key shares are allocated and issued to different smart contract participants according to target requirements, including:

Determine the target number of base private key shares allocated to smart contract participants according to the allocation weights corresponding to the smart contract participants, wherein the allocation weights are determined according to the trustworthiness of the smart contract participants and the degree of influence on the smart contract;

The target number of benchmark private key shares is issued to the corresponding smart contract participants, where the smart contract participants include the smart contract maker, the smart contract user and the smart contract arbitrator. The target number corresponding to the smart contract maker is greater than or equal to 1, the target number corresponding to the smart contract user is greater than or equal to 0, and the target number corresponding to the smart contract arbitrator is greater than or equal to 1.

Optionally, the state machine manager verifies the threshold signature based on the state change request, including:

The state machine manager obtains the reference public key corresponding to the reference private key from the smart contract, performs a hash operation on the state change request to obtain a second hash result, and calculates the verification public key share using the multiplicative inverse of the reference signature share, the reference public key, and the second hash result;

The state machine manager calculates the verification signature parameters based on the shared share of the verification public key, and determines whether the base signature parameters are equal to the verification signature parameters. If so, the verification is considered to be successful.

The present application provides a state changing device, comprising:

A request acquisition module, configured to acquire state change requests initiated by any smart contract participant;

The state hierarchical detection module is configured to trigger the state machine manager of the corresponding level to call the state machine of the corresponding level according to the different levels of the change object of the state change request, so as to detect the current state of the change object; wherein the level of the change object includes the smart contract layer or the function layer inside the smart contract, and the state machine managers and state machines corresponding to the change objects of different levels are different;

The state change module is configured to trigger the state machine manager of the corresponding level to call the state machine of the corresponding level if the current state of the change object meets the change condition, so as to change the state of the change object according to the state change request.

The present application provides a smart contract virtual machine, characterized in that it includes: a state machine manager and a state machine corresponding to the level of the change object, wherein the level of the change object includes the smart contract layer or the function layer inside the smart contract, and the state machine managers and state machines corresponding to the change objects at different levels are different.

The state machine manager is configured to detect the current state of the corresponding change object; and if the current state of the change object meets the change condition, call the state machine of the corresponding level to change the state of the change object according to the state change request.

The present application provides an electronic device, which includes a processor and a memory; wherein the memory is configured to store a computer program, and the computer program is loaded and executed by the processor to implement the aforementioned state change method.

The present application provides a computer non-volatile readable storage medium, in which computer executable instructions are stored. When the computer executable instructions are loaded and executed by a processor, the aforementioned state change method is implemented.

In this application, we first obtain a state change request initiated by any smart contract participant; then, based on the state change request, we change the state of the object to be changed. Different levels trigger the state machine manager of the corresponding level to call the state machine of the corresponding level to detect the current state of the changed object; wherein, the level of the changed object includes the smart contract layer or the functional function layer inside the smart contract, and the state machine managers and state machines corresponding to the changed objects of different levels are different; if the current state of the changed object meets the change conditions, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the changed object according to the state change request. It can be seen that this application designs multi-level lifecycle management, and the state machine manager and state machine of the level where the changed object is located work together to detect the current state of the changed object, and change the state when the change conditions are met. The lifecycle management of the entire smart contract is realized at the macro level of the smart contract, and the fine-grained lifecycle management of the function level is realized at the micro-function level, so as to protect the smart contract from vulnerabilities and ensure the stability of the blockchain system.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are merely embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

FIG1 is a flow chart of a state change method provided by the present application;

FIG2 is a schematic diagram of an optional state change method provided by the present application;

FIG3 is a flow chart of an optional state change method provided by the present application;

FIG4 is a state diagram of an optional first state machine provided by the present application;

FIG5 is a state diagram of an optional second state machine provided by the present application;

FIG6 is an optional smart contract lifecycle execution flow chart provided by the present application;

FIG7 is a flow chart of an optional state change method provided by the present application;

FIG8 is an optional threshold signature flow chart provided by the present application;

FIG9 is an optional signature verification flow chart provided by the present application;

FIG10 is a schematic diagram of the structure of a state changing device provided by the present application;

FIG. 11 is a structural diagram of a state-changing electronic device provided in the present application.

Detailed ways

The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

Due to the transparency, immutability and difficulty in repairing of smart contracts, smart contracts are easily targeted by hackers and can easily cause instability in the blockchain system. However, the existing lifecycle management for smart contracts is still imperfect, making the vulnerability protection ability of smart contracts weak. In view of the above technical defects, please provide a state change solution and design multi-level lifecycle management to protect smart contracts from vulnerabilities and ensure the stability of the blockchain system.

FIG1 is a flow chart of a state change method provided in an embodiment of the present application. Referring to FIG1 , the state change method includes:

S11: Get the state change request initiated by any smart contract participant.

In this embodiment, any party of the smart contract can initiate a state change request, and the smart contract participants include the smart contract developer, the smart contract user, and the smart contract arbitrator. When changing the state, first obtain the state change request initiated by any smart contract participant.

In this embodiment, the state change request can be to change the smart contract from the deployment state to the execution state, or to change the smart contract from the execution state to the stop state. This embodiment can realize the life cycle management of the fine-grained function level. Therefore, the state change request can be to change the state function inside the smart contract from the deployment state to the execution state, or to change the state function inside the smart contract from the execution state to the stop state. The specific state change logic is determined by the state machine corresponding to the smart contract and the state function.

It is understandable that the contract maker among the smart contract participants designs the smart contract, and the smart contract code must include the second state machine function, which is responsible for handling the second life cycle management. The smart contract code must include a function modifier, which can be used to determine the state of each function in a declarative manner. The smart contract code can contain multiple functional functions. Each smart contract must be judged before running. The state of the first state machine. If the first state machine is in the "execution" state, the contract can be called.

S12: According to the different levels of the changed object of the state change request, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to detect the current state of the changed object; wherein the level of the changed object includes the smart contract layer or the functional function layer within the smart contract, and the state machine managers and state machines corresponding to the changed objects of different levels are different.

In this embodiment, after obtaining the state change request, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level according to the different levels of the change object of the state change request to detect the current state of the change object. As mentioned above, the level of the change object includes the smart contract layer or the function layer inside the smart contract. The state machine manager and state machine corresponding to the change objects of different levels are different. The process includes (as shown in Figure 2):

S121: If the level of the change object of the state change request is the smart contract layer, the first state machine manager is triggered to call the first state machine to obtain the current first state machine state corresponding to the smart contract.

S122: Determine whether the current state of the first state machine meets the change condition;

In this embodiment, the smart contract corresponds to the first state machine manager and the first state machine, and the functional functions within the smart contract correspond to the first state machine manager and the first state machine. The first state machine manager and the first state machine manage the life cycle of the smart contract, and the second state machine manager and the second state machine manage the life cycle of the functional functions within the smart contract. That is, the first state machine is scheduled and managed by the first state machine manager to manage the first life cycle of the entire smart contract (the life cycle of the entire smart contract on a macro level). The second state machine is scheduled and managed by the second state machine manager to manage the second life cycle of the smart contract (the second state machine, as a function within the contract, runs within the contract and manages the life cycle of each specific function within the smart contract. It belongs to fine-grained function-level life cycle management).

In this embodiment, if the level of the change object of the state change request is the smart contract layer, the first state machine manager is triggered to call the first state machine to obtain the current first state machine state corresponding to the smart contract. It should be noted that the current state of the change object is reflected by the corresponding state machine state, so it is necessary to obtain the current first state machine state corresponding to the smart contract. After obtaining the state information, continue to determine whether the current first state machine state meets the change conditions.

S123: If the level of the change object of the state change request is the functional layer within the smart contract, the first state machine manager is triggered to call the first state machine to obtain the current first state machine state corresponding to the smart contract, and the second state machine manager is triggered to call the second state machine to obtain the current second state machine state corresponding to the functional function.

S124: Determine whether the current first state machine state and the current second state machine state both meet the change condition.

In this embodiment, if the level of the change object of the state change request is the function layer inside the smart contract, the first state machine manager is triggered to call the first state machine to obtain the current first state machine state corresponding to the smart contract, and the second state machine manager is triggered to call the second state machine to obtain the current second state machine state corresponding to the function function. The state change of the function function needs to be comprehensively judged in combination with the state of the smart contract to which it belongs and its own state. Therefore, the first state machine manager and the second state machine manager need to work at the same time to obtain the state of the smart contract and the function function. On this basis, it is judged whether the current first state machine state and the current second state machine state both meet the change conditions.

S13: If the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request.

In this embodiment, if the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request. Including (as shown in Figure 3):

S131: If the level of the change object of the state change request is the smart contract layer, trigger the first state machine manager to call the first state machine to change the state of the smart contract according to the state change request.

In this embodiment, when the state of the smart contract is detected, it is necessary to determine whether the current state of the first state machine belongs to the pre-state of the changed state required by the state change request. If so, it is determined that the current state of the first state machine meets the change condition. It should be noted that the state of the first state machine in this embodiment includes deployment, execution, stop, upgrade, and destruction, as shown in Figure 4. The second state machine includes deployment, execution, stop, and upgrade, as shown in Figure 5.

In this embodiment, the predecessor state of the changed state required by the state change request is a state that can be changed to the requested state. For example, for the first state machine, the deployment state is the predecessor state of the execution state, and the execution state is the predecessor state of the stop state.

S132: If the level of the change object of the state change request is the functional layer within the smart contract, the second state machine manager is triggered to call the second state machine to change the state of the functional function according to the state change request.

In this embodiment, when the state of the functional function inside the smart contract is detected, it is necessary to first determine whether the current state of the second state machine satisfies the hierarchical constraints of the state of the first state machine. If so, it is determined that both the state of the first state machine and the state of the second state machine meet the change conditions. The so-called hierarchical constraints mean that the microscopic smart contract state machine (second state machine) must follow the constraints of the macroscopic smart contract state machine (first state machine), and the second state machine must be changed under the permission of the first state machine rules. For example, if the first state machine is in a stopped state, then the second state machine cannot be in an execution, deployment, or upgrade state, and must comply with the constraints of the first state machine. In addition, before each functional function of this embodiment is run, it must determine the state it is in. If the first state machine is in the "execution" state and the second state machine is in the "execution" state, it can be executed. If its second state machine is in other states, execution is prohibited.

In this embodiment, when the hierarchical constraint condition is met, it is further possible to determine whether the current second state machine state is a pre-state of the changed state required by the state change request. If so, it is determined that both the first state machine state and the second state machine state meet the change condition. The judgment process is consistent with the macro smart contract and will not be repeated here.

This embodiment uses two state machines, and the smart contract lifecycle execution process is shown in Figure 6, which can realize fine-grained smart contract lifecycle management. When a function has a vulnerability, you only need to stop the corresponding function and upgrade it later, but it will not affect the execution of other functions in the smart contract, ensuring the stability of the blockchain system. When the entire smart contract has a vulnerability, the first state machine can be called to realize the state change of the entire smart contract and protect the security of the blockchain business.

It can be seen that the embodiment of the present application first obtains the state change request initiated by any smart contract participant; then, according to the different levels of the change object of the state change request, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to detect the current state of the change object; wherein, the level of the change object includes the smart contract layer or the functional function layer inside the smart contract, and the state machine manager and state machine corresponding to the change object of different levels are different; if the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request. The embodiment of the present application designs multi-level life cycle management, and the state machine manager and state machine of the level where the change object is located work together to detect the current state of the change object, and change the state when the change condition is met. The life cycle management of the entire smart contract is realized at the macro level of the smart contract, and the fine-grained life cycle management of the function level is realized at the micro-function level, so as to protect the smart contract from vulnerabilities and ensure the stability of the blockchain system.

FIG7 is a flow chart of an optional state change method provided in an embodiment of the present application. Referring to FIG7 , the state change method includes:

S21: Obtain a state change request initiated by any smart contract participant and a threshold signature of the state change request; wherein the threshold signature is obtained by the smart contract participant signing the state change request by means of a threshold signature.

The life cycle management of smart contracts is generally initiated by administrators or based on simple voting rules, without effective authority control. This embodiment designs a smart contract authority management principle based on threshold signatures on the basis of the previous embodiment, and realizes effective authority management of the smart contract life cycle. While obtaining a state change request initiated by any smart contract participant, it is also necessary to obtain the corresponding threshold signature. The threshold signature is obtained by the smart contract participant signing the state change request by means of a threshold signature.

In this embodiment, the steps for the smart contract participants to perform threshold signature include (as shown in Figure 8):

S211: The key generation center generates a base private key and a corresponding base private key share through a threshold secret sharing algorithm, and allocates and issues different base private key shares to different smart contract participants according to target requirements.

In this embodiment, the smart contract participants request the key generation center to generate the threshold signature key. The key generation center generates the base private key and the corresponding base private key share through the threshold secret sharing algorithm, and allocates and issues different base private key shares to different smart contract participants according to the target requirements. The threshold signature adopts a weighted approach, and each participant is allocated different private key shares according to the degree of trustworthiness and the degree of influence on the smart contract to achieve weight distribution.

Optionally, the key generation center sets the public parameters on the elliptic curve to initialize the system. The key generation center generates the public key P and private key d for the threshold signature. Set the threshold of the threshold signature to t+1, use Shamir threshold secret sharing to divide the private key into n shares, and send the n private keys to the smart contract participants. Among them, the smart contract maker has at least 1 private key share, the smart contract user has at least 0 private key shares, and the smart contract arbitrator has at least 1 private key share. Each smart contract participant has a different private key share, which can achieve different weights control permissions.

S212: Each smart contract participant generates multiple temporary private key shares and multiple temporary public key shares and sends the multiple temporary private key shares and multiple temporary public key shares to other smart contract participants respectively, and receives the temporary private key shares and temporary public key shares sent by other smart contract participants.

S213: Each smart contract participant calculates a temporary private key sharing share based on its own temporary private key share and the received temporary private key share, and calculates a temporary public key sharing share based on its own temporary public key share and the received public key and private key shares.

S214: Each smart contract participant calculates the base signature parameters based on the temporary public key sharing share.

In this embodiment, the smart contract developer attaches the public key P to the smart contract code as part of the smart contract. The smart contract participants execute the threshold signature technology on the request (these smart contract participants hold at least 2t+1 private key shares, 2t+1＜n. The characteristic of threshold signature is that the threshold is set to t+1, so at least 2t+1 individuals are required to participate). First, each smart contract participant generates multiple temporary private key shares, multiple temporary public key shares, and sends the multiple temporary private key shares and multiple temporary public key shares to other smart contract participants, and receives the temporary private key shares and temporary public key shares sent by other smart contract participants. Then each smart contract participant calculates the temporary private key sharing share based on its own temporary private key share and the received temporary private key share, and calculates the temporary public key sharing share based on its own temporary public key share and the received temporary public key share. Then each smart contract participant calculates the base signature parameter based on the temporary public key sharing share.

Optionally, each smart contract participant generates a corresponding share of the temporary private key k _i (random number). Then, the inverse of the share of the temporary private key k _i is calculated based on the share of the temporary private key. The public key (x, y) of the temporary private key k is calculated based on the share of the temporary public key k _i0 G, k _i1 G, .., k _i(2t+1) G. The reference signature parameter r is calculated based on the temporary public key (x, y).

S215: Each smart contract participant performs a hash operation on the state change request to obtain a first hash result, and signs the hash result to obtain a corresponding signature share, and uses a threshold signature to restore a base signature share based on each signature share.

S216: Each smart contract participant calculates a base signature parameter based on the base private key share, the temporary private key share, and the temporary public key share to obtain a threshold signature including the base signature parameter and the base signature share.

In this embodiment, each smart contract participant performs a hash operation on the state change request to obtain a first hash result, and signs the hash result to obtain a corresponding signature share, and restores the reference signature share using a threshold signature based on each signature share. Then, each smart contract participant calculates the reference signature parameter based on the reference private key share, the temporary private key share, and the temporary public key share to obtain a threshold signature containing the reference signature parameter and the reference signature share.

Taking the smart contract "deployment" as an example, a hash operation is performed on the first state machine change "deployment" operation deploy (deploy data includes information representing the smart contract) to obtain the operation result e. The signature share _si is calculated for e. The signature share si _is used to calculate the signature s. Finally, the signature result (r, s) is obtained.

S22: According to the different levels of the change object of the state change request, the state machine manager of the corresponding level is triggered to verify the threshold signature based on the state change request.

In this embodiment, after obtaining the request and threshold signature, the state machine manager of the corresponding level is triggered to verify the threshold signature based on the state change request according to the different levels of the change object of the state change request. If the level of the change object of the state change request is the smart contract layer, the first state machine manager is triggered to verify the threshold signature based on the state change request. If the level of the change object of the state change request is the function layer inside the smart contract, the second state machine manager is triggered to verify the threshold signature based on the state change request.

In this embodiment, the steps of the state machine manager verifying the threshold signature include (as shown in FIG. 9 ):

S221: The state machine manager obtains the reference public key corresponding to the reference private key from the smart contract, performs a hash operation on the state change request to obtain a second hash result, and calculates the verification public key sharing share using the multiplicative inverse of the reference signature share, the reference public key, and the second hash result.

S222: The state machine manager calculates the signature verification parameters according to the shared share of the signature verification public key, and determines whether the reference signature parameters are equal to the signature verification parameters. If so, the signature verification is determined to be successful.

In this embodiment, the state machine manager first obtains the reference public key corresponding to the reference private key from the smart contract, performs a hash operation on the state change request to obtain a second hash result, and calculates the verification public key share using the multiplicative inverse of the reference signature share, the reference public key, and the second hash result. Then the state machine manager calculates the verification signature parameter based on the verification public key share, and determines whether the reference signature parameter is equal to the verification signature parameter. If so, the verification is determined to be successful.

Still taking the smart contract "deployment" as an example, the "deployment" operation of the first state machine of the smart contract is sent to the first state machine manager, and the first state machine manager performs a signature verification operation. A hash operation is performed on the first state machine change "deployment" operation deploy (the deploy data includes information representing the smart contract) to obtain the operation result e. Calculate the multiplicative inverse s ^-1 of the signature s. Calculate the temporary public key (x′, y′). Calculate the signature parameter u and verify whether u is equal to r. If they are equal, the signature passes. The first state machine manager changes the first state machine of the smart contract to the "deployment" state.

S23: If the signature verification is passed, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level according to the different levels of the change object of the state change request, so as to detect the current state of the change object.

S24: If the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request.

In this embodiment, regarding the processes of the above-mentioned step S23 and step S24, reference may be made to the corresponding contents disclosed in the above-mentioned embodiments, and no further details will be given here.

It can be seen that in order to improve the authority control of the life cycle management of the smart contract, the embodiment of the present application adopts the threshold signature method to realize the authority control of the state machine change of the two-layer smart contract life cycle. Different participants have different private key shares, that is, different participants have different permissions to modify the life cycle of the smart contract. By adopting the threshold signature method, all participants do not need to sign, they only need to reach the corresponding signature threshold.

The following examples illustrate the threshold signature and signature verification process of smart contracts and the state changes of functional functions within smart contracts.

1. Execution of smart contracts

Change the "deployment" state of the first state machine of the smart contract to the "execution" state. The smart contract participants perform threshold signature technology on the "execution" request of the smart contract. First, each smart contract participant generates a corresponding shared share k _i of the temporary private key (a random number, where k _i is newly generated). Then, the inverse of the shared share k _i of the temporary private key is calculated based on the shared share of the temporary private key. The k public key (x, y) of the temporary private key is calculated based on the shared share k _i0 G, k _i1 G, .., k _i(2t+1) G of the temporary public key. The signature parameter r is calculated based on the temporary public key (x, y). A hash operation is performed on the "execution" request execute (the execute data includes information representing the smart contract) for the first state machine change to obtain the operation result e. Calculate the signature share s _i for e. The signature s is calculated using the signature share s _i . Finally, the signature result (r, s) is obtained.

Send the "execute" operation of the first state machine change of the smart contract to the first state machine manager, and the first state machine manager performs a signature verification operation. Perform a hash operation on the "execute" operation of the first state machine change (the execute data includes information representing the smart contract) to obtain the operation result e. Calculate the multiplicative inverse s ^-1 of the signature s. Calculate the temporary public key (x′, y′). Calculate the signature parameter u and verify whether u is equal to r. If they are equal, the signature passes. Determine whether the smart contract is in the "deployment" or "stop" state. If it is in these two states. The first state machine manager changes the state machine of the smart contract to the "execution" state.

2. Stop state operation of the function func1 of the smart contract

The smart contract participants perform threshold signature technology on the "stop" operation of the smart contract function func1. First, each smart contract participant generates a corresponding share of the temporary private key k _i (a random number, where k _i is newly generated). Then, based on the share of the temporary private key, Calculate the inverse of the shared share k _i of the temporary private key. Calculate the public key (x, y) of the temporary private key k based on the shared share k _i0 G, k _i1 G, .., k _i(2t+1) G of the temporary public key. Calculate the signature parameter r based on the temporary public key (x, y). For the second state machine of the function func1, change the "stop" operation stop (the stop data includes information representing the smart contract) to perform a hash operation to obtain the operation result e. Calculate the signature share s _i for e. Calculate the signature s using the signature share s _i . Finally, obtain the signature result (r, s).

The second state machine change "stop" operation of the function func1 of the smart contract is sent to the second state machine manager, and the second state machine manager performs a signature verification operation. Perform a hash operation on the second state machine change "stop" operation stop of the function func1 (the stop data includes information representing the smart contract) to obtain the operation result e. Calculate the multiplicative inverse s ^-1 of the signature s. Calculate the temporary public key (x′, y′). Calculate the signature parameter u and verify whether u is equal to r. If they are equal, the signature passes. Determine whether the smart contract is in the "execution" state and whether the function func1 is in the "execution" state. If both are in the "execution" state, the second state machine manager of the function func1 changes the state machine of the function func1 to the "stop" state. At this time, the operation of the second state machine is performed under the constraints of the first state machine.

In particular, the threshold signature and verification algorithm implementation process is as follows:

The key generation center first sets the public parameters on the elliptic curve, including p, q, E and G, where p is a large prime number, E is an elliptic curve defined on a finite field _Fp , and G = (x, y) is the base point of the qth order on the elliptic curve E. The key generation center sets the signature private key of the smart contract participant to d, and the public key to P = dG. The private key d is used to implement the signature of the smart contract life cycle change.

The key generation center implements the Shamir threshold secret sharing scheme. The key generation center splits the private key d of the elliptic curve into n parts and distributes them to the smart contract participants. Here, the number of participants is less than or equal to n. The participants negotiate the number of shares to be held based on the importance and credibility of the participants. For the convenience of representation, the n private keys are represented as U ₁ , U ₂ , …, _Un′ (Note: U _i , U _j can belong to the same smart contract participant). In order to achieve the security of smart contract changes, the smart contract arbitrator has at least 1 private key. Any t+1 or more smart contract participants can recover the private key d together to sign the changes to the smart contract state machine.

The process of generating private key shares is:

1. The key generation center constructs a t-order polynomial Wherein the private key d = f(0) = a ₀ . _{a i} represents the coefficient of the polynomial.

2. The key generation center calculates d _i = f(i) and sends the partial private key d _i to the smart contract participants by establishing an SSL trusted channel.

3. Smart contract participant U _i keeps _di as its own private key in secret and does not disclose it to anyone.

At this time, any set C of t+1 smart contract participants can be interpolated by the Lagrange interpolation formula

Temporary private key share generation:

1. First, 2t+1′ smart contract participants are selected, and each of the 2t+1′ smart contract participants generates a 2t-order polynomial, i = {1, 2, ..., 2t+1}, j = {1, 2, ..., 2t+1}, k _ij ∈ Z _q .

2. The polynomial for the i′th participant is:

_fi (x)＝ _ki0 + _ki1x +...+ _ki(2t+1) ^x2tmodq

3. Then each smart contract participant i secretly _{sends fi} (j)j={1, 2,…, 2t+1} to other smart contract participants, and of course also sends the shared shares of the temporary public key k _i0 G, .k _i1 G, .., k _i(2t+1) G to other smart contract participants.

4. Other smart contract participants each calculate the corresponding share of the temporary private key
k _i =∑fj(i), j={1, 2, ..., 2t+1};

5. Simultaneously calculate the inverse of the temporary private key share k _i

6. Calculate the public key of the temporary private key k

7. Calculate the previous parameter r = x mod q.

T+1 signature generation:

1. Perform hash calculation on the smart contract status change transaction message to obtain:
e = sha256(sha256(message))

2. Calculate s _i , i = {1, 2, ..., 2t+1}

Where d _i is the shared share corresponding to the private key.

3. Use threshold signature to recover s.

4. The signature is (r, s).

Signature Verification:

1. The public key is P = dG, and the signature is (r, s)

2. Perform a hash operation on the plain text of the message to obtain: e = sha256 (sha256 (message))

3. Compute the multiplicative inverse of s, s ^-1 .

4. Calculate s ^-1 (eG + r (PK)) = (x', y')

5. Calculate u = x′ mod q and verify whether u is equal to r.

As shown in FIG10 , the embodiment of the present application further discloses a state changing device, including:

A request acquisition module 11 is configured to acquire a state change request initiated by any smart contract participant;

The state hierarchical detection module 12 is configured to trigger the state machine manager of the corresponding level to call the state machine of the corresponding level according to the different levels of the change object of the state change request, so as to detect the current state of the change object; wherein the level of the change object includes the smart contract layer or the function layer inside the smart contract, and the state machine managers and state machines corresponding to the change objects of different levels are different;

The state change module 13 is configured to trigger the state machine manager of the corresponding level to call the state machine of the corresponding level if the current state of the change object meets the change condition, so as to change the state of the change object according to the state change request.

It can be seen that the embodiment of the present application first obtains the state change request initiated by any smart contract participant; then, according to the different levels of the change object of the state change request, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to detect the current state of the change object; wherein, the level of the change object includes the smart contract layer or the functional function layer inside the smart contract, and the state machine manager and state machine corresponding to the change object of different levels are different; if the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request. The embodiment of the present application designs multi-level life cycle management, and the state machine manager and state machine of the level where the change object is located work together to detect the current state of the change object, and change the state when the change condition is met. The life cycle management of the entire smart contract is realized at the macro level of the smart contract, and the fine-grained life cycle management of the function level is realized at the micro-function level, so as to protect the smart contract from vulnerabilities and ensure the stability of the blockchain system.

In some optional embodiments, the state classification detection module 12 includes:

A first triggering unit is configured to trigger the first state machine manager to call the first state machine to obtain a current first state machine state corresponding to the smart contract if the level of the change object of the state change request is the smart contract layer;

A first judging unit is configured to judge whether the current state of the first state machine satisfies a change condition;

The second trigger unit is configured to trigger the first state machine manager to call the first state machine to obtain the current first state machine state corresponding to the smart contract, and trigger the second state machine manager to call the second state machine to obtain the current second state machine state corresponding to the function if the level of the change object of the state change request is the function layer inside the smart contract;

The second judgment unit is configured to judge whether the current first state machine state and the current second state machine state both meet the change condition.

In some optional embodiments, the state change module 13 includes:

A third triggering unit is configured to trigger the first state machine manager to call the first state machine to change the state of the smart contract according to the state change request;

The fourth trigger unit is configured to trigger the second state machine manager to call the second state machine to change the state of the functional function according to the state change request.

In some optional embodiments, the first judgment unit is configured to judge whether the current first state machine state is a pre-state of the changed state required by the state change request, and if so, determine that the current first state machine state meets the change condition.

In some optional embodiments, the second judgment unit is configured to determine whether the current second state machine state satisfies the hierarchical constraint conditions of the first state machine state, and to determine whether the current second state machine state belongs to the predecessor state of the changed state required by the state change request. If so, it is determined that both the first state machine state and the second state machine state meet the change conditions.

In some optional embodiments, the request obtaining module 11 includes:

The first acquisition unit is configured to acquire a state change request initiated by any smart contract participant

The second acquisition unit is configured to obtain a threshold signature of the state change request; wherein the threshold signature is obtained by the smart contract participant signing the state change request by means of a threshold signature.

In some optional embodiments, the state changing device further includes:

The signature verification module is configured to trigger the state machine manager of the corresponding level to verify the threshold signature based on the state change request according to the different levels of the change object of the state change request. If the verification passes, the step of detecting the current state of the change object is executed.

The base private key share generation module is configured as a key generation center to generate a base private key and a corresponding base private key share through a threshold secret sharing algorithm, and allocate and issue different base private key shares to different smart contract participants according to target requirements;

A temporary public and private key share generation module is configured to generate multiple temporary private key shares and multiple temporary public key shares for each smart contract participant and send the multiple temporary private key shares and multiple temporary public key shares to other smart contract participants respectively, and receive the temporary private key shares and temporary public key shares sent by other smart contract participants;

A temporary public-private key sharing share generation module is configured so that each smart contract participant calculates a temporary private key sharing share based on its own temporary private key share and the received temporary private key share, and calculates a temporary public key sharing share based on its own temporary public key share and the received temporary public key share;

A base signature parameter generation module is configured to calculate base signature parameters for each smart contract participant based on a temporary public key sharing share;

The threshold signature generation module is configured so that each smart contract participant respectively performs a hash operation on the state change request to obtain a first hash result, and respectively signs the hash result to obtain a corresponding signature share, and uses the threshold signature to restore the base signature share based on each signature share; each smart contract participant calculates the base signature parameter based on the base private key share, the temporary private key share and the temporary public key share to obtain a threshold signature including the base signature parameter and the base signature share.

In some optional embodiments, the signature verification module includes:

The first signature verification unit is configured to trigger the first state machine manager to verify the threshold signature based on the state change request if the level of the change object of the state change request is the smart contract layer;

The second signature verification unit is configured to trigger the second state machine manager to verify the threshold signature based on the state change request if the level of the change object of the state change request is the function layer inside the smart contract.

In some optional embodiments, the signature verification module is configured as a state machine manager to obtain a reference public key corresponding to a reference private key from a smart contract, perform a hash operation on a state change request to obtain a second hash result, and calculate a verification public key sharing share using the multiplicative inverse of the reference signature share, the reference public key, and the second hash result; the state machine manager calculates the verification signature parameters based on the verification public key sharing share, and determines whether the reference signature parameters are equal to the verification signature parameters. If so, the verification is determined to be successful.

Furthermore, an embodiment of the present application also provides an electronic device. FIG11 is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content in the diagram cannot be regarded as any limitation on the scope of application of the present application.

FIG11 is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input/output interface 25, and a communication bus 26. The memory 22 is configured to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the state change method disclosed in any of the aforementioned embodiments.

In this embodiment, the power supply 23 is configured to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be configured as the technical solution of the present application, and is not limited here; the input and output interface 25 is configured to obtain external input data or output data to the outside world, and its interface type can be selected according to application needs and is not specifically limited here.

In addition, the memory 22, as a carrier for storing resources, can be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon may include an operating system 221, a computer program 222 and data 223, etc. The storage method can be temporary storage or permanent storage.

The operating system 221 is configured to manage and control the hardware devices and computer programs 222 on the electronic device 20 to realize the operation and processing of the massive data 223 in the memory 22 by the processor 21, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be configured to complete the state change method performed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks. The data 223 can include the state change request collected by the electronic device 20.

Furthermore, an embodiment of the present application also discloses a non-volatile readable storage medium, in which a computer program is stored. When the computer program is loaded and executed by a processor, the state change method steps disclosed in any of the aforementioned embodiments are implemented.

In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

The state change request method, device, equipment and non-volatile readable storage medium provided by the present application are introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims (20)

1. A state change method, characterized by comprising:

   Get state change requests initiated by any smart contract participant;

   According to the different levels of the change object of the state change request, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to detect the current state of the change object; wherein the level of the change object includes the smart contract layer or the function layer inside the smart contract, and the state machine managers and state machines corresponding to the change objects of different levels are different;

   If the current state of the change object meets the change condition, the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level to change the state of the change object according to the state change request.
2. The state change method according to claim 1 is characterized in that the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level according to the different levels of the change object of the state change request to detect the current state of the change object, including:

   If the level of the change object of the state change request is the smart contract layer, triggering the first state machine manager to call the first state machine to obtain the current first state machine state corresponding to the smart contract;

   Determine whether the current state of the first state machine meets the change condition;

   Correspondingly, if the current state of the change object meets the change condition, the triggering of the state machine manager of the corresponding level calls the state machine of the corresponding level to change the state of the change object according to the state change request, including:

   Trigger the first state machine manager to call the first state machine to change the state of the smart contract according to the state change request.
3. The state change method according to claim 2, characterized in that the triggering of the first state machine manager to call the first state machine to change the state of the smart contract according to the state change request comprises:

   In a case where the state change request is used to request the smart contract layer to change the state of the first state machine from a deployment state to an execution state, detecting whether the smart contract is in the deployment state or the stop state;

   When the smart contract is in the deployed state or the stopped state, the state machine of the smart contract is changed to the executed state, wherein the first state machine state includes the deployed state and the executed state.
4. The state changing method according to claim 2, characterized in that the step of determining whether the current state of the first state machine satisfies the change condition comprises:

   It is determined whether the current first state machine state is a pre-state of the changed state required by the state change request, and if so, it is determined that the current first state machine state meets the change condition.
5. The state change method according to claim 1 is characterized in that the state machine manager of the corresponding level is triggered to call the state machine of the corresponding level according to the different levels of the change object of the state change request to detect the current state of the change object, including:

   If the level of the change object of the state change request is the function layer inside the smart contract, the first state machine manager is triggered to call the first state machine to obtain the current first state machine state corresponding to the smart contract, and the second state machine manager is triggered to call the second state machine to obtain the current second state machine state corresponding to the function;

   Determine whether the current first state machine state and the current second state machine state both meet the change conditions;

   Correspondingly, if the current state of the change object meets the change condition, the triggering of the state machine manager of the corresponding level calls the state machine of the corresponding level to change the state of the change object according to the state change request, including:

   The second state machine manager is triggered to call the second state machine to change the state of the functional function according to the state change request.
6. The state change method according to claim 5, characterized in that the triggering of the second state machine manager to call the second state machine to change the state of the functional function according to the state change request comprises:

   In the case where the state change request is used to request the function layer to perform a stop state operation, detecting whether the smart contract is in in an execution state, and detecting whether the functional function layer is in an execution state;

   When the smart contract is in the execution state and the functional function layer is in the execution state, the second state machine state is changed to the stop state, and the second state machine state includes the execution state and the stop state.
7. The state changing method according to claim 5, characterized in that the step of determining whether both the current first state machine state and the current second state machine state satisfy the change condition comprises:

   It is determined whether the current second state machine state satisfies the hierarchical constraint condition of the first state machine state. If so, it is determined that both the first state machine state and the second state machine state satisfy the change condition.
8. The state changing method according to claim 7, characterized in that the step of determining whether the current second state machine state satisfies the hierarchical constraint condition of the first state machine state comprises:

   Matching a first state machine state with a second state machine state, wherein the first state machine state includes a deployment state, an execution state, a stop state, an upgrade state, and a destruction state, and the second state machine state includes a deployment state, an execution state, a stop state, and an upgrade state;

   When the second state machine state matches the first state machine state, it is determined that the second state machine state satisfies the hierarchical constraint condition of the first state machine state.
9. The state change method according to claim 7 is characterized in that after determining whether the current second state machine state satisfies the hierarchical constraint condition of the first state machine state, it further comprises:

   It is determined whether the current second state machine state is a pre-state of the changed state required by the state change request, and if so, it is determined that both the first state machine state and the second state machine state meet the change condition.
10. The state change method according to any one of claims 1 to 9, characterized in that obtaining a state change request initiated by any smart contract participant comprises:

    Obtain a state change request initiated by any smart contract participant and a threshold signature of the state change request; wherein the threshold signature is obtained by the smart contract participant signing the state change request by means of a threshold signature;

    Accordingly, before detecting the current state of the changed object, the following steps are also included:

    According to the different levels of the change object of the state change request, the state machine manager of the corresponding level is triggered to verify the threshold signature based on the state change request. If the verification passes, the step of detecting the current state of the change object is executed.
11. The state change method according to claim 10, characterized in that the triggering of the state machine manager of the corresponding level to verify the threshold signature based on the state change request according to the different levels of the change object of the state change request comprises:

    If the level of the change object of the state change request is the smart contract layer, the first state machine manager is triggered to verify the threshold signature based on the state change request.
12. The state change method according to claim 10, characterized in that the triggering of the state machine manager of the corresponding level to verify the threshold signature based on the state change request according to the different levels of the change object of the state change request comprises:

    If the level of the change object of the state change request is the functional layer within the smart contract, the second state machine manager is triggered to verify the threshold signature based on the state change request.
13. The state changing method according to claim 10, characterized in that it also includes:

    Each of the smart contract participants performs a hash operation on the state change request to obtain a first hash result, and signs the hash result to obtain a corresponding signature share, and restores a reference signature share using a threshold signature according to each of the signature shares;

    Each of the smart contract participants calculates a baseline signature parameter based on the baseline private key share, the temporary private key share, and the temporary public key share to obtain the threshold signature including the baseline signature parameter and the baseline signature share.
14. The state changing method according to claim 13, further comprising:

    The key generation center generates a reference private key and a corresponding reference private key share through a threshold secret sharing algorithm, and allocates and issues different reference private key shares to different smart contract participants according to target requirements;

    Each of the smart contract participants generates a plurality of temporary private key shares, a plurality of temporary public key shares and sends the plurality of temporary private key shares to the smart contract. The temporary private key share and the temporary public key share are sent to other smart contract participants respectively, and the temporary private key share and the temporary public key share are received from other smart contract participants;

    Each smart contract participant calculates a temporary private key share based on its own temporary private key share and the received temporary private key share, and calculates a temporary public key share based on its own temporary public key share and the received temporary public key share;

    Each of the smart contract participants calculates the reference signature parameters based on the temporary public key sharing share.
15. The state change method according to claim 14 is characterized in that different shares of the base private key are allocated and issued to different smart contract participants according to target requirements, including:

    Each smart contract participant allocates the benchmark private key share according to the degree of trustworthiness and the degree of influence on the smart contract to achieve weight allocation, wherein the smart contract participants include smart contract makers, smart contract users and smart contract arbitrators, the number of benchmark private key shares allocated by the smart contract makers is greater than or equal to 1, the number of benchmark private key shares allocated by the smart contract users is greater than or equal to 0, and the number of benchmark private key shares allocated by the smart contract arbitrators is greater than or equal to 1.
16. The state change method according to claim 14, characterized in that the state machine manager verifies the threshold signature based on the state change request, comprising:

    The state machine manager obtains a reference public key corresponding to the reference private key from the smart contract, performs a hash operation on the state change request to obtain a second hash result, and calculates a verification public key sharing share using the multiplicative inverse of the reference signature share, the reference public key, and the second hash result;

    The state machine manager calculates the signature verification parameter according to the shared share of the signature verification public key, and determines whether the reference signature parameter is equal to the signature verification parameter. If so, it is determined that the signature verification is passed.
17. A state changing device, characterized by comprising:

    A request acquisition module, configured to acquire state change requests initiated by any smart contract participant;

    A state hierarchical detection module is configured to trigger a state machine manager of a corresponding level to call a state machine of a corresponding level according to different levels of the change object of the state change request, so as to detect the current state of the change object; wherein the level of the change object includes a smart contract layer or a function layer within a smart contract, and the state machine managers and state machines corresponding to the change objects of different levels are different;

    The state change module is configured to trigger the state machine manager of the corresponding level to call the state machine of the corresponding level if the current state of the change object meets the change condition, so as to change the state of the change object according to the state change request.
18. A smart contract virtual machine, characterized in that it comprises: a state machine manager and a state machine corresponding to the level of a change object, wherein the level of the change object comprises a smart contract layer or a function layer within a smart contract, and the state machine manager and the state machine corresponding to the change objects at different levels are different,

    The state machine manager is configured to detect the current state of the corresponding change object; and if the current state of the change object meets the change condition, call the state machine of the corresponding level to change the state of the change object according to the state change request.
19. An electronic device, characterized in that the electronic device includes a processor and a memory; wherein the memory is configured to store a computer program, and the computer program is loaded and executed by the processor to implement the state change method as described in any one of claims 1 to 16.
20. A computer non-volatile readable storage medium, characterized in that it is configured to store computer executable instructions, and when the computer executable instructions are loaded and executed by a processor, the state change method according to any one of claims 1 to 16 is implemented.