Proposal voting method

Abstract

This invention discloses a proposal voting method. This method encapsulates a voting proposal management component outside the functional logic of a smart contract, acting as an intermediary for calling the functional logic. The voting proposal management component manages the lifecycle of voting proposals within the smart contract through its exposed query, proposal, voting, and execution interfaces. This allows users to execute the contract's functional logic via smart contracts on a blockchain platform after authorization and authentication by multiple users. Because this invention is independent of the smart contract's implementation language, functional logic, and deployment method, users can freely extend the method described in this invention to design smart contracts on any blockchain platform and in any language, requiring multi-user authorization.

Description

[0001] This application is a divisional application of Chinese Patent Application No. 2019111882018, filed on December 28, 2019, entitled "A Lifecycle Management Method for Voting Proposals Based on Smart Contracts", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of blockchain technology, and in particular to a method for voting on proposals. Background Technology

[0003] Blockchain is a new type of decentralized protocol that can securely store digital currency transactions or other data. The information cannot be forged or tampered with. Transaction confirmation on the blockchain is completed jointly by all nodes on the blockchain, and its consistency is guaranteed by a consensus algorithm. A public ledger is maintained on the blockchain to store the balances of all users on the blockchain network. The public ledger is visible to any node on the storage block, thus ensuring that it cannot be forged or tampered with.

[0004] Due to its unique chain-like data storage structure, blockchain makes it difficult to directly perform CRUD operations on structured data. However, developing smart contracts can put structured data on the chain and perform related operations.

[0005] Blockchain smart contracts are essentially executable languages ​​on the blockchain, operating similarly to other computer program statements to interact with real-world assets and other data. Smart contracts are often written in a high-level language like Solidity (a specialized language similar to JavaScript).

[0006] Structured data, also known as row data, is data logically expressed and implemented using a two-dimensional table structure. It strictly adheres to data format and length specifications and is primarily stored and managed through relational databases. By establishing a one-to-one mapping between two-dimensional table structure data and the storage structure in smart contracts, structured data can be stored and managed on the blockchain through smart contracts.

[0007] Most existing smart contract execution permission controls are based on single-user address checks. When smart contracts need to assign permissions to multiple users, multi-signature technology is the only option. However, multi-signature technology can only evenly distribute permissions across a specified number of addresses. Furthermore, to acquire the desired permission, signatures from all authorized accounts are required. This multi-user permission allocation method is inflexible in terms of weighting and permission thresholds, making it difficult to use in complex permission allocation schemes. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides a proposal voting method, which offers a general solution to the multi-user authorization problem in smart contracts on blockchains. The specific technical solution is as follows:

[0009] A method for managing the lifecycle of voting proposals based on smart contracts includes the following steps:

[0010] Step 1: Initialize the contract:

[0011] By embedding or deploying contracts, a voting proposal contract is created on the blockchain, requiring permission from several users with voting rights for logical execution. The voting proposal contract includes: a voting proposal management component and several functional components responsible for executing specific logic. Each functional component has its own data structure and functions, but the functions are not exposed to the outside of the contract, meaning they cannot be directly called by users, but can only be indirectly called through the voting proposal management component.

[0012] Step Two: Perform corresponding operations on the voting proposal contract according to the user's needs, thereby changing the proposal status:

[0013] (1) When a proposal is initiated to execute a non-exposed function of a contract through voting, the initiator determines the target function and parameters of the smart contract to be called. On the client side, based on the mapping table from identifiers to function functions in the voting proposal management component and the data serialization protocol, the information of the required function and parameters is converted into function identifiers and parameter serialization strings. Then, the function identifiers and parameter serialization strings are used as parameters for the contract call, and a request with a digital signature is sent to the blockchain node in the form of a contract call transaction to call the externally exposed proposal function of the voting proposal management component. After the transaction is sent to the blockchain node, the digital signature is verified first, and then consensus is reached. After the consensus is reached, a block timestamp consistent with all blockchain nodes is generated, which is the transaction packaging timestamp. After this, when the executor of the blockchain node runs the requested proposal function, it is executed in the following sub-steps:

[0014] (1.1) Check the existing proposals in the contract status data: If there are no proposals in the current status data, proceed directly to step (1.2); If there are proposals in the contract status data and the proposals have timed out, first set the proposal status in the status data to "timeout", and then proceed to step (1.2); If there are proposals in the current status data and the proposals have not timed out, proceed directly to step (1.2).

[0015] (1.2) Check the correctness of both new and existing proposals;

[0016] For a new proposal, if the initiator of the transaction in the contract call transaction can be found in the mapping table from voter address to weight, the target function identifier can be correctly mapped to the corresponding function according to the mapping table from identifier to function, and the serialization parameter string can be correctly converted into the parameters required by the function according to the serialization protocol, then step (1.3) will be executed; otherwise, an error will be returned and the process will exit.

[0017] For existing proposals, if the current status data shows the proposal status as "timeout", "prohibited" or "effective", then proceed to step (1.3); otherwise, return an error and exit.

[0018] (1.3) Update the proposal in the contract state data;

[0019] The existing proposal is destroyed from the state data, and the proposal counter in the state data is incremented by one, with the result serving as the number of the new proposal. The initiator, function identifier, parameter serialization string, proposal number, and proposal timeout timestamp generated based on the transaction packaging timestamp and the proposal timeout limit contained in the current transaction are combined to form the information of the new proposal. Then, the status of the new proposal is set to "Approved". After that, the proposal data is stored in the state data. Finally, the proposal data is serialized, and the information of the new proposal is pushed to the clients of other users with voting rights through the message interface provided by the blockchain platform.

[0020] (2) When a user with voting rights receives a push notification of a proposal and wishes to vote on it: the voter assesses the consequences of contract execution based on the obtained proposal information, and then generates opinions supporting or opposing the proposal; the voter combines the proposal number, the transaction packaging time of the proposal, and their own vote on the client to generate a request with a digital signature and sends it to the blockchain node to call the vote function of the voting proposal contract; after receiving the request, the blockchain node first verifies the signature of the request and then performs consensus; after the consensus is completed, a block timestamp consistent with all blockchain nodes is generated, i.e., the transaction packaging timestamp; after this, when the executor of the blockchain node runs the vote function called by the request, it is executed in the following sub-steps:

[0021] (2.1) Check the existing proposals in the contract state data: If there are no proposals in the current state data, return an error and exit; if there are proposals in the contract state data and the proposals have timed out, set the proposal status in the state data to timeout, then return an error and exit; if there are proposals in the current state data and the proposals have not timed out, proceed to step (2.2).

[0022] (2.2) Check the correctness of the vote: If the sender of the vote can be found in the mapping table from the voter address to the weight, the proposal number and the transaction packaging time of the proposal in the voting request are equal to the proposal number and transaction packaging time in the contract state data, and the proposal status in the current contract state data is approved, then the vote is considered correct, and step (2.3) is executed; otherwise, an error is returned and the process exits.

[0023] (2.3) Update voting results: If a voter agrees to implement the proposal, the voter's address is updated in the list of voters who agree to the proposal in the contract state data. Then, based on the mapping table between the list of voters who agree to the proposal and the voter's address to the weight, the total weight of the voters who agree to the proposal is calculated. If the calculated result is greater than or equal to the minimum threshold for the proposal to pass, the current proposal status in the contract state data is updated to "passed," and a message consisting of the proposal's status, number, and transaction timestamp is sent to the proposal initiator through the message interface provided by the blockchain platform, and then the execution ends. If a voter opposes the implementation of the proposal, the voter's address is updated in the list of opponents in the proposal in the contract state data. Then, based on the mapping table between the list of opponents and the voter's address to the weight, the total weight of the opponents and the total weight of all voters are calculated. If the total weight of all voters minus the total weight of the opponents is less than the minimum threshold for the proposal to pass, the proposal status in the contract state data is updated to "prohibited," and a message consisting of the proposal's status, number, and transaction timestamp is sent to the proposal initiator through the message interface provided by the blockchain platform, and then the execution ends. If neither the total weight of the voters who agree to the proposal nor the total weight of the opponents exceeds the threshold, the execution ends directly.

[0024] (3) When a proposal initiator wishes to execute its own proposal: The initiator should use the proposal number and transaction packaging timestamp attached to the message as parameters to generate a request to call the execute function of the contract on the client and send it to the blockchain node; After receiving the request, the blockchain node first verifies the signature of the request and then performs consensus; After consensus is reached, a block timestamp consistent with all blockchain nodes is generated, which is the transaction packaging timestamp; After this, the executor of the blockchain node runs the execute function of the request call, which is executed in the following sub-steps:

[0025] (3.1) Check the existing proposals in the contract state data: If there are no proposals in the current state data, return an error and exit; if there are proposals in the contract state data and the proposals have timed out, set the proposal status in the state data to timed out, then return an error and exit; if there are proposals in the current state data and the proposals have not timed out, proceed to step (3.2).

[0026] (3.2) Check the correctness of the execution request: If the initiator of the execution request is the initiator of the proposal in the current contract state data, and the proposal number and transaction packaging timestamp in the execution request are equal to the proposal number and transaction packaging time in the current contract state data, and the proposal in the current contract state data is passed, then the execution request is considered correct, and proceed to step (3.3); otherwise, the execution will end directly, an error will be returned and the process will exit.

[0027] (3.3) Execute proposal: Based on the mapping table from function identifier to target function, the target function identifier contained in the current proposal in the contract state data is mapped to the function to be executed in the proposal. Then, the parameter serialization string is converted into actual parameters through the deserialization protocol, the target function is called to actually execute, and the execution result is converted into a string through the serialization protocol and stored in the receipt.

[0028] (4) When a user wants to query a proposal in the contract state: The user constructs a request with a digital signature on the client and sends it to the blockchain node to call the query function of the proposal voting contract; after receiving the request, the blockchain node first verifies the signature of the request and then performs consensus; after the consensus is completed, a block timestamp consistent with all blockchain nodes is generated, that is, the transaction packaging timestamp; after this, when the executor of the blockchain node runs the query execution function called by the request, it is executed in the following sub-steps:

[0029] (4.1) Check the existing proposals in the contract status data. If there are no proposals in the current status data, return an error and exit. If there are proposals in the contract status data and the proposals have timed out, set the proposal status in the status data to timeout and then proceed to step (4.2). If there are proposals in the current status data and the proposals have not timed out, proceed to step (4.2).

[0030] (4.2) Check the correctness of the query request. If the sender of the vote can be found in the mapping table of voter address to weight, the query request is considered correct and the serialization result of the proposal will be returned directly; otherwise, an error will be returned and the process will exit.

[0031] Furthermore, the voting proposal management component described in step one includes the following features: a mapping table from voter addresses to weights, a mapping table from identifiers to function names, a data serialization and deserialization protocol, a proposal data structure definition, a proposal counter, a proposal timeout limit, a weight threshold required for a proposal to pass, and four function interfaces exposed to the outside of the contract: proposal, vote, execute, and query.

[0032] Furthermore, the method for determining whether a proposal has timed out is to compare the timeout timestamp of the proposal with the transaction packaging timestamp. If the timeout timestamp of the proposal is greater than or equal to the transaction packaging timestamp, then the proposal has not timed out; if the timeout timestamp of the proposal is less than the transaction packaging timestamp, then the proposal has timed out.

[0033] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0034] (1) This invention is applied to smart contracts on blockchain platforms that require multiple signatures to authorize the execution of actual logic. This invention provides a universal voting proposal lifecycle management method for the design of this type of smart contract that is independent of the implementation language of the smart contract, the actual execution logic of the smart contract, and the deployment method of the smart contract. It provides a solution for realizing blockchain multi-signature authorization based on voting proposal smart contracts, and is easier to maintain and expand.

[0035] (2) This method uses the transaction packaging time of smart contract call requests that is consistent across all blockchain nodes as the basis for judging "timeout", eliminating the need to maintain a timer. It leverages the characteristics of blockchain systems to provide a solution for designing a "timeout" state mechanism in a distributed environment. Attached Figure Description

[0036] Figure 1 This is a collaboration diagram between the four administrators who invoke smart contracts through proposals and the blockchain system;

[0037] Figure 2 This is a diagram illustrating the state changes throughout the lifecycle of a proposal in a voting proposal contract;

[0038] Figure 3 This is a schematic diagram illustrating the process by which a blockchain node handles a request to invoke the voting proposal contract. Detailed Implementation

[0039] The present invention will be described in detail below with reference to the accompanying drawings and specific implementation examples, and the purpose and effects of the present invention will become more apparent.

[0040] like Figure 1-3 As shown, a method for managing the lifecycle of voting proposals based on smart contracts includes the following steps:

[0041] Step 1: Initialize the contract:

[0042] By embedding or deploying contracts, a voting proposal contract is created on the blockchain, requiring permission from several users with voting rights for its logical execution. The voting proposal contract includes a voting proposal management component and several functional components responsible for executing specific logic. Each functional component has its own data structure and functions, but these functions are not exposed externally; that is, they cannot be directly called by users, but only indirectly through the voting proposal management component. The voting proposal management component includes the following features: a mapping table from voter addresses to weights, a mapping table from identifiers to functional functions, a data serialization and deserialization protocol, a proposal data structure definition, a proposal counter, a proposal timeout limit, and the weight threshold required for a proposal to pass. It exposes four function interfaces externally: `proposal` (for proposals), `vote` (for voting), and `execute` (for execution and querying).

[0043] Step Two: Perform corresponding operations on the voting proposal contract according to the user's needs, thereby changing the proposal status:

[0044] (1) When a proposal is initiated to execute a non-exposed function of a contract through voting: The initiator determines the target function and parameters of the smart contract to be called. On the client side, based on the mapping table from identifiers to function functions in the voting proposal management component and the data serialization protocol, the information of the required function and parameters is converted into function identifiers and parameter serialization strings. Then, the function identifiers and parameter serialization strings are sent as parameters for the contract call to the blockchain node in the form of a contract call transaction with a digital signature, calling the proposal function exposed by the voting proposal contract. After the transaction is sent to the blockchain node, the digital signature is verified first, and then consensus is reached. After consensus is reached, a block timestamp consistent with all blockchain nodes is generated, i.e., the transaction packaging timestamp. After this, when the executor of the blockchain node runs the requested proposal function, it is executed in the following sub-steps:

[0045] 1) Check the existing proposals in the contract state data. If there are no proposals in the current state data, proceed directly to the next sub-step. If there are proposals in the contract state data, and the timeout timestamp of the proposal is less than the transaction packaging timestamp, set the proposal status in the state data to "timeout" and proceed to the next sub-step. If there are proposals in the current state data, and the timeout timestamp of the proposal is greater than the transaction packaging timestamp, proceed directly to the next sub-step.

[0046] 2) Check the correctness of both new and existing proposals.

[0047] For a new proposal, if the initiator of the transaction in the contract call transaction can be found in the mapping table from voter address to weight, the target function identifier can be correctly mapped to the corresponding function according to the mapping table from identifier to function, and the serialization parameter string can be correctly converted into the parameters required by the function according to the serialization protocol, then step (1.3) will be executed; otherwise, an error will be returned and the process will exit.

[0048] For existing proposals, if the current status data shows the proposal status as "timeout", "prohibited" or "effective", then proceed to step (1.3); otherwise, return an error and exit.

[0049] 3) Update the proposal in the contract state data. Destroy existing proposals from the state data and increment the proposal counter in the state data; the result serves as the number of the new proposal. Combine the initiator, function identifier, parameter serialization string, proposal number, and the proposal timeout timestamp generated based on the transaction packaging timestamp and the proposal timeout limit from the current transaction to form the information of the new proposal. Then, set the status of the new proposal to "Approved." After this, store the proposal data in the state data. Finally, serialize the proposal data and push the new proposal information to the clients of other users with voting rights through the message interface provided by the blockchain platform.

[0050] (2) When a user with voting rights receives a push notification of a proposal and wishes to vote on it: The voter assesses the consequences of contract execution based on the received proposal information, and then generates a support or opposition opinion for the proposal. The voter combines the proposal number, the transaction packaging time of the proposal, and their own vote on the client side to generate a request with a digital signature and sends it to the blockchain node to invoke the vote function of the voting proposal contract. Upon receiving the request, the blockchain node first verifies the signature of the request and then performs consensus. After consensus is reached, a consistent block timestamp, i.e., the transaction packaging timestamp, is generated across all blockchain nodes. After this, the executor of the blockchain node runs the vote function invoked in the request, which is executed in the following sub-steps:

[0051] 1) Check the existing proposals in the contract state data. If there are no proposals in the current state data, return an error and exit. If there are proposals in the contract state data, and the timeout timestamp of the proposal is less than the transaction packaging timestamp, set the proposal status in the state data to "timeout", then return an error and exit. If there are proposals in the current state data, and the timeout timestamp of the proposal is greater than the transaction packaging time, proceed to the next sub-step.

[0052] 2) Check the correctness of the vote. If the sender of the vote can be found in the mapping table from voter address to weight, the proposal number and transaction packaging time of the proposal in the vote request are equal to the proposal number and transaction packaging time in the contract state data, and the proposal status in the current contract state data is "approved", then the vote is considered correct, and the next sub-step is executed; otherwise, an error is returned and the process exits.

[0053] 3) Update voting results. If a voter agrees to implement the proposal, their address is updated in the list of agreeors in the contract state data. Then, based on the mapping table between the list of agreeors and the voter addresses to weights, the total weight of the voters who agree to the proposal is calculated. If the calculated result is greater than or equal to the minimum threshold for the proposal to pass, the current proposal status in the contract state data is updated to "Passed," and a message consisting of the proposal's status, number, and transaction timestamp is sent to the proposal initiator via the message interface provided by the blockchain platform. Then, execution ends. If a voter opposes the implementation of the proposal, their address is updated in the list of opponents in the contract state data. Then, based on the mapping table between the list of opponents and the voter addresses to weights, the total weight of the opponents and the total weight of all voters are calculated. If the total weight of all voters minus the total weight of the opponents is less than the minimum threshold for the proposal to pass, the proposal status in the contract state data is updated to "Prohibited," and a message consisting of the proposal's status, number, and transaction timestamp is sent to the proposal initiator via the message interface provided by the blockchain platform. Then, execution ends.

[0054] (3) When a proposal initiator wishes to execute its own proposal: The initiator should use the proposal number and transaction packaging timestamp attached to the message as parameters to generate a request call to the `execute` function of the contract on the client side and send it to the blockchain node. After receiving the request, the blockchain node first verifies the signature of the request and then performs consensus. After consensus is reached, a block timestamp consistent with all blockchain nodes is generated, i.e., the transaction packaging timestamp. After this, the executor of the blockchain node runs the `execute` function of the request call, which is executed in the following sub-steps:

[0055] 1) Check the existing proposals in the contract state data. If there are no proposals in the current state data, return an error and exit. If there are proposals in the contract state data, and the timeout timestamp of the proposal is less than the transaction packaging timestamp, set the proposal status in the state data to "timeout", then return an error and exit. If there are proposals in the current state data, and the timeout timestamp of the proposal is greater than the transaction packaging time, proceed to the next sub-step.

[0056] 2) Check the correctness of the execution request. If the initiator of the execution request is the initiator of the proposal in the current contract state data, and the proposal number and transaction packaging timestamp in the execution request are equal to the proposal number and transaction packaging time in the current contract state data, and the proposal in the current contract state data is approved, then the execution request is considered correct, and proceed to the next sub-step. Otherwise, terminate the execution directly, return an error, and exit.

[0057] 3) Execute the proposal. Based on the mapping table from function identifiers to target functions, the target function identifiers contained in the current proposal in the contract state data are mapped to the functions to be executed in the proposal. Then, the parameter serialization string is converted into actual parameters through the deserialization protocol, the target function is called to actually execute, and the execution result is converted into a string through the serialization protocol and stored in the receipt.

[0058] (4) When a user wants to query a proposal in the contract state: The user constructs a request with a digital signature on the client and sends it to the blockchain node to invoke the query function of the proposal voting contract. After receiving the request, the blockchain node first verifies the signature of the request and then performs consensus. After consensus is reached, a block timestamp consistent with all blockchain nodes is generated, i.e., the transaction packaging timestamp. After this, when the executor of the blockchain node runs the query execution function invoked by the request, it is executed in the following sub-steps:

[0059] 1) Check the existing proposals in the contract state data. If there are no proposals in the current state data, return an error and exit. If there are proposals in the contract state data, and the timeout timestamp of the proposal is less than the transaction packaging timestamp, set the proposal status in the state data to "timeout" and proceed to the next sub-step. If there are proposals in the current state data, and the timeout timestamp of the proposal is greater than the transaction packaging time, proceed to the next sub-step.

[0060] 2) Check the validity of the query request. If the sender of the vote can be found in the mapping table of voter addresses to weights, the query request is considered valid, and the serialized result of the proposal will be returned directly; otherwise, an error will be returned and the process will exit.

[0061] The smart contract deployed in step one does not directly expose the functional module interfaces; it only exposes the interface of the voting proposal component. Functional module interfaces need to upload proposals through the voting proposal component and are indirectly invoked after a vote. At any given time, the contract state data either contains no proposals or only one proposal; multiple proposals are not allowed.

[0062] Any call to the voting proposal smart contract made in step two may cause a change in the proposal status in the contract state data. Specifically, a call to the `proposal` function may cause the proposal status to be set to "timeout," or the entire proposal may be updated and its status set to "approved"; a call to the `vote` function may cause the proposal status to be set to "timeout," "prohibited," or "passed"; a call to the `execute` function may cause the proposal status to be set to "timeout" or "effective"; and a call to the `query` function may cause the proposal status to be set to "timeout." A proposal status being set to "timeout" is caused by the transaction packaging timestamp of the contract call exceeding the proposal's timeout timestamp, regardless of which contract function is called.

Claims

1. A method for voting on proposals, characterized in that, Applied to blockchain nodes, the method includes: The new proposal is sent to multiple clients, all of which have the right to vote on the proposal. After receiving the new proposal, the multiple clients return a voting request to the blockchain node. The voting request carries the proposal number and vote of the new proposal. The vote is either a support or opposition to the new proposal. The voting request is used to request the call to the vote function of the voting proposal contract. If the voting requests sent by the multiple clients are received, the vote function invoked in the request is executed to perform the following operations: For each of the plurality of clients, if the vote in the voting request sent by one of the clients is a support opinion, the voter address of that client is added to the list of agreeors of the new proposal; or, if the vote in the voting request sent by one of the clients is a dissent opinion, the voter address of that client is added to the list of opponents of the new proposal. Based on the list of consenters and the stored mapping table of voter addresses to weights, the total weight of voters who consent to the implementation of the new proposal is determined, and based on the list of dissidents and the mapping table of voter addresses to weights, the total weight of voters who dissent against the implementation of the new proposal is determined. The proposal status of the new proposal is updated based on the total weight of the voters who agree to implement the new proposal or the total weight of the voters who oppose the implementation of the new proposal. The proposal status is either passed or prohibited. Before adding the voter's address to the list of agreeors of the new proposal if the vote in the voting request sent by a client is a supporting opinion, or adding the voter's address to the list of opponents of the new proposal if the vote in the voting request sent by a client is a dissenting opinion, the method further includes checking the correctness of the proposal and voting request in the contract state data, specifically including: Check the contract status data for any proposals. If no proposal is found in the contract status data, an error message will be displayed and the operation will be terminated. If a proposal exists in the contract status data, and the proposal in the contract status data has timed out, then the proposal status of the proposal in the contract status data is set to timed out, an error message is issued, and the operation is terminated. If a proposal exists in the contract status data and the proposal has not timed out, then check the correctness of the voting request sent by the client; if the voting request sent by the client is correct, then execute the step of adding the voter address of the client to the list of agreeors of the new proposal if the vote in the voting request sent by the client is a support opinion, or adding the voter address of the client to the list of opponents of the new proposal if the vote in the voting request sent by the client is a dissent opinion; The voting request also includes a transaction packaging timestamp of the new proposal, and the check of the correctness of the voting request sent by the client includes: If the voter address of the client can be found in the mapping table from the voter address to the weight, and the proposal number carried in the voting request sent by the client is the same as the proposal number of the proposal existing in the contract status data, and the transaction packaging timestamp carried in the voting request sent by the client is the same as the transaction packaging timestamp of the proposal existing in the contract status data, and the proposal status of the proposal existing in the contract status data is "approval", then the voting request sent by the client is determined to be correct; otherwise, the voting request sent by the client is determined to be incorrect. Before sending the new proposal to multiple clients, the process also includes: Receive contract call transaction, the contract call transaction being used to request the invocation of the proposal function of the voting proposal contract; The new proposal is generated based on the transaction invoked according to the contract. Run the proposal function invoked in the request to perform the following actions: Check the contract status data for any proposals. If no proposal is found in the contract status data, then the correctness of the new proposal is checked. If the new proposal is correct, increment the proposal counter in the contract status data by 1 to obtain the proposal number of the new proposal; Set the proposal status of the new proposal to approval and store the new proposal in the contract status data.

2. The method as described in claim 1, characterized in that, The step of updating the proposal status of the new proposal based on the total weight of the voters who agree to implement the new proposal or the total weight of the voters who oppose the implementation of the new proposal includes: If the total weight of the voters who agree to implement the new proposal is greater than or equal to the minimum weight threshold for the new proposal to pass, then the proposal status of the new proposal is updated to passed; or, Based on the voter address of each of the multiple clients and the mapping table from the voter address to the weight, the total weight of all voters is determined. If the difference between the total weight of all voters and the total weight of the voters who oppose the implementation of the new proposal is less than the minimum weight threshold for the new proposal to pass, then the proposal status of the new proposal is updated to prohibited.

3. The method as described in claim 1, characterized in that, The contract call transaction carries a target function identifier and a parameter serialization string. The check of the correctness of the new proposal includes: If the address of the initiator of the contract call transaction can be found in the mapping table from the voter address to the weight, and the target function identifier carried by the contract call transaction can be correctly mapped to the corresponding function according to the stored mapping table from the identifier to the function, and the parameter serialization string carried by the contract call transaction can be correctly converted into the parameters required by the function, then the new proposal is determined to be correct; otherwise, the new proposal is determined to be incorrect.

4. The method as described in claim 1, characterized in that, After checking whether a proposal exists in the contract status data, the process also includes: If a proposal exists in the contract status data, and the proposal has expired, the proposal status of the proposal in the contract status data will be set to expired; if the proposal has not expired, the proposal status of the proposal in the contract status data will not be processed. If the proposal status of a proposal existing in the contract status data is timed out, prohibited, or effective, then the proposal existing in the contract status data is destroyed, and the proposal counter in the contract status data is incremented by 1 to obtain the proposal number of the new proposal. Set the proposal status of the new proposal to approval and store the new proposal in the contract status data.

5. The method according to any one of claims 1-4, characterized in that, The contract invocation transaction carries a digital signature, and before generating the new proposal based on the contract invocation transaction, the process further includes: Verify the digital signature of the contract call transaction; After the digital signature verification of the contract call transaction is passed, the step of generating the new proposal based on the contract call transaction is executed; Before the proposal function called by the execution request, the following is also included: A consensus was reached on the new proposal; After the consensus on the new proposal is reached, a block timestamp consistent with all blockchain nodes is generated as the transaction packaging timestamp for the new proposal.

6. The method as described in claim 5, characterized in that, The contract call transaction carries a target function identifier and a parameter serialization string, and setting the proposal status of the new proposal to "before approval" further includes: The updated new proposal includes the proposal number of the new proposal, the address of the initiator of the contract call transaction, the target function identifier and the parameter serialization string carried by the contract call transaction, and the transaction packaging timestamp and timeout timestamp of the new proposal.

7. The method as described in any one of claims 1-2, characterized in that, After updating the proposal status of the new proposal, the process also includes: If the proposal status of the new proposal is updated to "passed", a proposal pass message is sent to the initiator of the new proposal. The proposal pass message carries the proposal status, proposal number and transaction packaging timestamp of the new proposal.

8. The method as described in claim 1, characterized in that, After updating the proposal status of the new proposal, the process also includes: Receive a proposal execution request, wherein the proposal execution request is used to request the invocation of the execute function of the proposal voting contract; Run the execute function invoked in the request to perform the following operations: Check the contract status data for any proposals. If no proposal is found in the contract status data, an error message will be displayed and the operation will be terminated. If a proposal exists in the contract status data, and the proposal in the contract status data has timed out, then the proposal status of the proposal in the contract status data is set to timed out, an error reminder is given, and the operation is terminated. If a proposal exists in the contract status data and the proposal in the contract status data has not timed out, then check the correctness of the proposal execution request. If the proposal execution request is correct, execute the new proposal.

9. The method as described in claim 1, characterized in that, The proposal execution request carries the proposal number and transaction packaging timestamp of the new proposal. The check of the correctness of the proposal execution request includes: If the initiator of the proposal execution request is the initiator of a proposal existing in the contract status data, and the proposal number carried by the proposal execution request is the same as the proposal number of a proposal existing in the contract status data, and the transaction packaging timestamp carried by the proposal execution request is the same as the transaction packaging timestamp of a proposal existing in the contract status data, and the proposal status of a proposal existing in the contract status data is "passed", then the proposal execution request is determined to be correct; otherwise, the proposal execution request is determined to be incorrect.

10. The method as described in claim 8 or 9, characterized in that, The new proposal includes an objective function identifier and a parameter serialization string. Executing the new proposal includes: Based on the stored identifier-to-function mapping table, the target function identifier contained in the new proposal is mapped to the target function to be executed by the new proposal, and the parameter serialization string contained in the new proposal is converted into actual parameters through the stored deserialization protocol; The target function is called using the actual parameters to obtain the execution result of the target function. The execution result is then converted into a string using a stored serialization protocol and stored in a receipt. Update the proposal status of the new proposal to "effective".

11. The method as described in claim 1, characterized in that, The method further includes: Receive a query request, the query request being used to request the invocation of the query function of the proposal voting contract; Run the query function invoked in the request to perform the following operations: Check if there is a proposal in the contract status data; at most one proposal exists in the contract status data. If no proposal is found in the contract status data, an error message will be displayed and the operation will be terminated. If a proposal exists in the contract status data, and the proposal has timed out, the proposal status of the proposal in the contract status data will be set to timeout. If the proposal has not timed out, no action will be taken on the proposal status of the proposal in the contract status data. The correctness of the query request will be checked. If the query request is correct, the serialization result of the proposal in the contract status data will be returned. If the query request is incorrect, an error message will be displayed and the operation will be terminated.

12. The method as described in claim 11, characterized in that, The process of checking the correctness of the query request includes: If the address of the initiator of the query request can be found in the mapping table from the voter's address to the weight, then the query request is determined to be correct; otherwise, the query request is determined to be incorrect.

13. The method according to any one of claims 1, 3, 8, and 10, characterized in that, The proposals in the contract state data include timeout timestamps and transaction packaging timestamps, and the method further includes: If the timeout timestamp of a proposal in the contract status data is less than the transaction packaging timestamp, then it is determined that the proposal in the contract status data has timed out. If the timeout timestamp of a proposal in the contract state data is greater than or equal to the transaction packaging timestamp, then it is determined that the proposal in the contract state data has not timed out.

Images