Block chain voting governance method and system and related products

Abstract

The invention discloses a block chain voting governance method and system and related products, the method is applied to a governance agent node, a voting message body of a user node with the governance right is received, and the voting message body comprises an identifier of a proposal supported by voting. And determining an identifier for obtaining the target proposal supported by the maximum number of votes based on each received voting message body, generating a Merkel tree through Hash operation according to each received voting message body, and taking a root of the Merkel tree obtained through operation as a voting root. And writing the voting root and the identifier of the target proposal into the governance contract on the chain. Visibly, only the voting root and the identifier of the target proposal are written into the governance contract on the chain through the governance agent node, and all related operations in the voting governance process do not need to be stored on the chain, so that the governance efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a blockchain voting governance method, system and related products. Background Art

[0002] At present, with the rapid development of blockchain technology, blockchain technology has penetrated into various industries, resulting in a large number of governance needs in blockchain systems. Governance refers to the process of joint decision-making by stakeholders in the network when performing operations such as contract code upgrades in the blockchain network.

[0003] Blockchain voting governance can be used in various organizations, communities or projects. Each participant can propose a proposal and express their intentions through voting. At the same time, the blockchain voting governance process also includes counting votes, verifying voting results, and executing voting results. Currently, blockchain governance adopts pure on-chain voting governance, which stores all voting-related operations of all users on the chain. However, each on-chain storage must wait for the consensus of the entire network, resulting in low governance efficiency.

[0004] Therefore, how to improve the governance efficiency of blockchain voting governance has become an urgent problem to be solved in the current field. Summary of the invention

[0005] The embodiments of the present application provide a blockchain voting governance method, system and related products, aiming to improve the governance efficiency of blockchain voting governance.

[0006] The first aspect of the present application provides a blockchain voting governance method, which is applied to a governance proxy node, comprising:

[0007] Receive a voting message body from a user node with governance rights, where the voting message body includes an identifier of a proposal voted for;

[0008] Determine the identifier of the target proposal that has received the most votes based on each received voting message body, generate a Merkle tree through hash operation based on each received voting message body, and use the root of the Merkle tree obtained by the operation as the voting root;

[0009] Write the voting root and the identifier of the target proposal into the governance contract on the chain.

[0010] The second aspect of the present application provides a blockchain voting governance method, which is applied to the governance contract on the chain, including:

[0011] Receive the voting root and the identifier of the target proposal submitted by the governance proxy node to the chain; the voting root is the root of the Merkle tree generated by the governance proxy node through hash operation according to each received voting message body, and the target proposal is the proposal that has obtained the most votes supported by the governance proxy node based on each received voting message body; the voting message body includes the identifier of the proposal voted for;

[0012] Receiving a governance challenge request from a user node, wherein the governance challenge request carries a Merkle path being challenged;

[0013] Provide the Merkle path to the governance proxy node.

[0014] The third aspect of the present application provides a blockchain voting governance system, including: a plurality of user nodes with governance rights, a governance contract on a blockchain, and a governance proxy node;

[0015] The user node is used to send a voting message body to the governance proxy node, where the voting message body includes an identifier of a proposal voted for;

[0016] The governance proxy node is used to receive the voting message body of the user node with governance rights; determine the identity of the target proposal that has obtained the most votes based on each received voting message body, and generate a Merkle tree through hash operation based on each received voting message body, and use the root of the Merkle tree obtained by operation as the voting root; write the voting root and the identity of the target proposal into the governance contract;

[0017] The governance contract is used to receive the voting root and target proposal identifiers submitted by the governance proxy node to the chain;

[0018] The user node is further used to send a governance questioning request to the governance contract when there is doubt about the voting governance, and the governance questioning request carries the Merkle path being questioned;

[0019] The governance contract is also used to provide the questioned Merkle path to the governance proxy node.

[0020] A fourth aspect of the present application provides a blockchain voting governance device, the device comprising a processor and a memory:

[0021] The memory is used to store a computer program and transmit the computer program to the processor;

[0022] The processor is used to execute the steps of the blockchain voting governance method provided by the first aspect, or execute the steps of the blockchain voting governance method provided by the second aspect according to the instructions in the computer program.

[0023] The fifth aspect of the present application provides a computer-readable storage medium, which is used to store a computer program. When the computer program is executed by a blockchain voting governance device, it implements the steps of the blockchain voting governance method provided in the first aspect, or executes the steps of the blockchain voting governance method provided in the second aspect.

[0024] The sixth aspect of the present application provides a computer program product, including a computer program, which, when executed by a blockchain voting governance device, implements the steps of the blockchain voting governance method provided in the first aspect, or executes the steps of the blockchain voting governance method provided in the second aspect.

[0025] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0026] The present application provides a blockchain voting governance method, system and related products in an embodiment. The method is applied to a governance proxy node. In the method, a voting message body of a user node with governance rights is received, and the voting message body includes the identification of the proposal voted for. Based on each received voting message body, the identification of the target proposal that has received the most votes is determined, and a Merkle tree is generated by hashing based on each received voting message body, and the root of the Merkle tree obtained by the operation is used as the voting root. The voting root and the identification of the target proposal are written into the governance contract on the chain.

[0027] It can be seen that after receiving the voting message body of the user node with governance rights, the proposal identifier with the most votes can be determined based on each voting message body, and the Merkle tree composed of each voting message body can be obtained through hash operation, so that the Merkle tree root can be used as the voting root. Therefore, only the voting root and the identifier of the target proposal can be written into the governance contract on the chain through the governance proxy node, without the need to store all related operations in the voting governance process on the chain, thereby improving governance efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 A scenario architecture diagram of a blockchain voting governance method provided in an embodiment of the present application;

[0029] Figure 2 A schematic diagram of the structure of a distributed system provided in an embodiment of the present application;

[0030] Figure 3 A schematic diagram of a block structure provided in an embodiment of the present application;

[0031] Figure 4A A flowchart of a blockchain voting governance method provided in an embodiment of the present application;

[0032] Figure 4BA flowchart of another blockchain voting governance method provided in an embodiment of the present application;

[0033] Figure 5 A schematic diagram of the structure of a Merkle tree provided in an embodiment of the present application;

[0034] Figure 6 A schematic diagram of a voting governance interaction process provided in an embodiment of the present application;

[0035] Figure 7 A schematic diagram of another voting governance interaction process provided in an embodiment of the present application;

[0036] Figure 8 A schematic diagram of an interactive process for verifying the effectiveness of voting governance provided in an embodiment of the present application;

[0037] Fig. 9A A flowchart of another blockchain voting governance method provided in an embodiment of the present application;

[0038] Fig. 9B A flowchart of another blockchain voting governance method provided in an embodiment of the present application;

[0039] Fig.10 A schematic diagram of the structure of a blockchain voting governance system provided in an embodiment of the present application;

[0040] Fig.11 A schematic diagram of the structure of the server in the embodiment of the present application;

[0041] Fig.12 A schematic diagram of the structure of a terminal device in an embodiment of the present application. DETAILED DESCRIPTION

[0042] At present, there are a large number of governance needs in the blockchain system. Currently, pure on-chain voting governance can be adopted. For example, a decentralized governance system based on pure on-chain voting governance will store all users' voting-related operations on the chain to ensure the transparency of governance. However, each storage on the chain requires waiting for the consensus of the entire network, resulting in low governance efficiency of pure on-chain voting governance.

[0043] Therefore, how to improve the governance efficiency of blockchain voting governance has become an urgent problem to be solved in the current field.

[0044] In view of the above problems, a blockchain voting governance method, system and related products are provided in this application, the purpose of which is to improve the governance efficiency of blockchain voting governance. In the technical solution provided in this application, the voting message body is received in the governance proxy node, and the voting root is obtained based on the voting message body calculation, and the voting root and the identifier of the target proposal are written into the governance contract on the chain. User votes are collected and counted in the governance proxy node, and only the identifier and voting root of the target proposal are recorded on the chain. There is no need to store all related operations in the voting governance process on the chain, thereby improving governance efficiency.

[0045] First, several terms that may be involved in the embodiments of the present application are explained below.

[0046] Blockchain: A data structure consisting of several blocks connected by hash values. Each block consists of transactions generated within a period of time, packaged by computer nodes that have obtained the right to record accounts, and independently verified by each computer node.

[0047] Full node: refers to a complete node that maintains the blockchain, which can independently complete the packaging and verification of transactions, and process the client's read and write requests for the status of smart contracts.

[0048] Governance: refers to the process of joint decision-making by stakeholders in the blockchain network when performing operations such as contract code upgrades, protocol upgrades, and rate changes. This is called governance.

[0049] Smart contract: It is generally believed that a smart contract refers to a computer program that can automatically execute contract terms, with features such as event-driven, value transfer, and automatic execution.

[0050] The execution subject of the blockchain voting governance method provided by the embodiment of the present application may be a terminal device. For example, the terminal device acts as a governance proxy node and receives the voting message body of the user node with governance rights. As an example, the terminal device may specifically include but is not limited to mobile phones, desktop computers, tablet computers, laptops, PDAs, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, etc. The execution subject of the blockchain voting governance method provided by the embodiment of the present application may also be a server, that is, the server acts as a governance proxy node, receives the voting message body of the user node with governance rights, and determines the voting root based on the voting message body, and writes the voting root and the identifier of the target proposal into the governance contract on the chain.

[0051] The blockchain voting governance method provided in the embodiment of the present application can also be executed collaboratively by the terminal device and the server. For example, each terminal device acts as a governance proxy node, and the server acts as a governance contract on the chain. The terminal device uses the method provided in the embodiment of the present application to write the voting root and the identification of the target proposal into the governance contract on the chain. The server then receives the identification of the voting root and the target proposal, receives the governance questioning request from the user node, and finally provides the governance proxy node with the Merkel path questioned in the governance questioning request. Therefore, in the embodiment of the present application, there is no limitation on the implementation subject of the technical solution of the present application.

[0052] Figure 1 The following is an example of a scenario architecture diagram of a blockchain voting governance method, which includes a server and various forms of terminal devices. Figure 1 The server shown can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. In addition, the server can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms.

[0053] The blockchain voting governance method involved in the embodiment of the present application can be applied to a distributed system formed by connecting a client and multiple nodes (any form of computing device in the access network, such as a server and a user terminal) through network communication.

[0054] Take the distributed system as the blockchain system as an example, see Figure 2 , Figure 2 This is an optional structural diagram of the distributed system 100 provided by the embodiment of the present invention applied to the blockchain system, which is formed by multiple nodes (any form of computing devices in the access network, such as servers, user terminals) and clients, and a point-to-point network is formed between the nodes. In a distributed system, any machine such as a server or a terminal can join and become a node, and the node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0055] See also Figure 2 The functions of each node in the blockchain system shown include:

[0056] 1) Routing: a basic function of a node, used to support communication between nodes.

[0057] In addition to the routing function, the node can also have the following functions:

[0058] 2) Applications are deployed in the blockchain to implement specific businesses based on actual business needs, record data related to the implementation of functions to form record data, carry digital signatures in the record data to indicate the source of the task data, and send the record data to other nodes in the blockchain system for other nodes to add the record data to a temporary block when they successfully verify the source and integrity of the record data.

[0059] For example, the services implemented by the application include:

[0060] 2.1) Wallet, used to provide the function of conducting electronic currency transactions, including initiating transactions (i.e., sending the transaction record of the current transaction to other nodes in the blockchain system. After the other nodes successfully verify the transaction, as a response to acknowledge the validity of the transaction, the transaction record data is stored in the temporary block of the blockchain; of course, the wallet also supports querying the remaining electronic currency in the electronic currency address;

[0061] 2.2) Shared ledger, which is used to provide functions such as storage, query and modification of account data. The record data of the operation on the account data is sent to other nodes in the blockchain system. After other nodes verify the validity, as a response to acknowledging the validity of the account data, the record data is stored in a temporary block, and a confirmation can also be sent to the node that initiated the operation.

[0062] 2.3) Smart contracts are computerized protocols that can execute the terms of a contract. They are implemented by deploying code on a shared ledger that is executed when certain conditions are met. The code is used to complete automated transactions based on actual business needs, such as querying the logistics status of the goods purchased by the buyer and transferring the buyer's electronic currency to the merchant's address after the buyer signs for the goods. Of course, smart contracts are not limited to executing contracts for transactions, but can also execute contracts for processing received information.

[0063] 3) Blockchain, including a series of blocks that are connected to each other in the order of their generation. Once a new block is added to the blockchain, it will not be removed. The block records the record data submitted by the nodes in the blockchain system.

[0064] See also Figure 3 , Figure 3This is an optional schematic diagram of the block structure provided by an embodiment of the present invention. Each block includes the hash value of the transaction record stored in this block (the hash value of this block) and the hash value of the previous block. Each block is connected by the hash value to form a blockchain. In addition, the block can also include information such as the timestamp when the block was generated. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains relevant information for verifying the validity of its information (anti-counterfeiting) and generating the next block.

[0065] Figure 4A A flowchart of a blockchain voting governance method provided in an embodiment of the present application. Figure 4A In the blockchain voting governance method shown, the method is applied to the governance proxy node, including:

[0066] S401: Receive a voting message body from a user node with governance rights, where the voting message body includes an identifier of a proposal voted for.

[0067] The governance of blockchain smart contracts has two processes, one is that the owner of the governance right votes on the governance proposal, and the other is to verify each voting record in the voting process. The governance proxy node refers to the proxy node that processes the vote. It is the node that actually runs the blockchain accounting program, maintains the blockchain world state data, and processes blockchain transactions. It is used to receive the user's vote and generate a voting certificate on the chain. The governance proxy node can receive the user's vote through the Internet, that is, the voting message body, and then upload the voting root and the target proposal identifier to the chain for storage based on the Internet. Therefore, the governance proxy node can be a node on other blockchains or an independently running node, but the governance proxy node is not on the blockchain where the smart contract that needs to be governed is located. Among them, the governance proxy node can be determined by the blockchain where the smart contract that needs to be governed is located, and the governance proxy node can also be determined by negotiation or proposal between user nodes with governance rights.

[0068] As an example, the business scope of a smart contract is to handle loan business. When the interest rate needs to be increased or decreased in the loan business, blockchain voting governance is required. Then this smart contract is the smart contract that needs to be governed this time. The user node with governance rights can initiate a proposal to increase the interest rate by 0.5%, and then the participants of this voting governance can vote. Generally, the voting results will be uploaded to the blockchain for storage and verification. However, the participants do not trust each other enough. For example, participant A is worried that participant B did not participate in the vote. At this time, the participants can jointly negotiate and determine a governance proxy node as the carrier for receiving voting messages, and then the governance proxy node will upload the voting message results to the blockchain for storage and verification. Alternatively, a governance proxy node can also be determined by the smart contract that needs to be governed.

[0069] In one possible implementation, at the beginning of voting governance, a voting proposal is initiated by a user with governance rights, and a storage slot can be inserted into the governance contract. The storage slot is a storage tuple consisting of four elements, for example, Contract.Storage =<M,N,State_root,Vote_root> , Contract.Storage is a storage tuple inserted into the governance contract, which is the storage of the governance contract on the chain. The first element of the storage slot is the identifier of the starting governance block. The starting governance block is the block on the blockchain that records the start time of voting governance. The identifier of the starting governance block can be represented by the block height M, which refers to the number of blocks connected to the blockchain. The second element of the storage slot is the identifier of the ending governance block. The ending governance block is the block on the blockchain that records the end time of voting governance. The identifier of the ending governance block can be represented by the block height N. The third element of the storage slot is the state root of the state tree at the start time of voting governance. The state root refers to the root of the tree composed of the summary of the state of all accounts on the blockchain at the start time of voting governance, that is, the root of the tree composed of the hash values ​​of all blocks on the blockchain at the start time of voting governance. The state root can be represented by State_root. The fourth element of the storage slot is used to fill in the voting root before ending governance. The voting root can be represented by Vote_root. Since the voting root is unknown when governance begins, the fourth element of the storage slot can be left empty, that is, it can be recorded as a value of 0. When governance begins, only the block height M, block height N, and the value of the state root State_root can be written into the storage slot.

[0070] In a possible implementation, since the block height M is the identifier of the starting governance block, and the block height N is the identifier of the ending governance block, that is, block M is the block on the blockchain that records the start time of voting governance, and block N is the block on the blockchain that records the end time of voting governance. During the period from block M to block N, the smart contracts and governance proxy nodes that need to be governed can receive votes from external users with governance rights, where users with governance rights can vote through user nodes, that is, user nodes with governance rights can send voting message bodies to governance proxy nodes, then smart contracts and governance proxy nodes that need to be governed can receive voting message bodies from external user nodes with governance rights. Specifically, users with governance rights can sign with their own private keys and send a voting message body consisting of voting content and signatures to the governance proxy node.

[0071] As an example, Vote_body i =<Vote_index,Address,Signature> , Vote_body i Represents the voting message body of the i-th vote, Vote_index represents the option subscript in the proposal that the user wants to support, Address represents the address of the voting user, and Signature represents the signature of the supported proposal by the user using the private key corresponding to the address, that is, the voting user signs Vote_index using the private key corresponding to the user's address.

[0072] S402: Determine the identifier of the target proposal that has received the most votes based on the received voting message bodies, generate a Merkle tree through hash operation based on the received voting message bodies, and use the root of the Merkle tree obtained by the operation as the voting root.

[0073] After receiving voting message bodies from different users, the governance agent node can arrange the voting message bodies. For example, a Merkle tree can be generated through hash operations based on each voting message body. The Merkle tree is a hash tree. Each node is marked with a hash value of a data block. The hash value of the data block can be calculated through a hash algorithm.

[0074] In a possible implementation manner, the root of the Merkle tree formed by each voting message body may be calculated and obtained by formula 1.

[0075] Vote_root=MERKLE_ROOT(∨Vote_body i )(Formula 1)

[0076] Among them, Vote_root means that each voting message body Vote_body iThe root of the Merkle tree generated by hash operation, MERKLE_ROOT() is the function for generating the Merkle tree root, and V in Formula 1 is the union symbol.

[0077] As an example, the Merkle tree can be found in Figure 5 , Figure 5 A schematic diagram of the structure of a Merkle tree provided in an embodiment of the present application.

[0078] Figure 5 The voting message bodies in the Merkle tree correspond to the voting contents of different user nodes, voting message body 1-1, voting message body 1-2, voting message body 2-1, voting message body 2-1 corresponds to the voting contents of different user nodes, the hash value of voting message body 1-1 in the Merkle tree can be represented by H(1,1), the hash value of voting message body 1-2 in the Merkle tree can be represented by H(1,2), the hash values ​​of two adjacent nodes are paired and merged to generate the hash value of the intermediate node, which can be represented by H(1,:). The hash value of voting message body 2-1 in the Merkle tree can be represented by H(2,1), the hash value of voting message body 2-2 in the Merkle tree can be represented by H(2,2), the hash values ​​of two adjacent nodes are paired and merged to generate the hash value of the intermediate node, which can be represented by H(2,:), and finally the hash values ​​of the two intermediate nodes are paired and merged to obtain the root Vote_root of the Merkle tree.

[0079] Since the hash value of each voting message body is recorded in the Merkle tree, after the Merkle tree root is obtained through the calculation of Formula 1, the Merkle tree root can be used as the voting root, that is, the voting proof in this governance process.

[0080] At the same time, since the voting message body contains the option subscripts in the proposals that the user wants to support, the identifier of the target proposal that receives the most votes can be determined based on the received voting message bodies.

[0081] In addition, since the blockchain governance process also includes the execution of voting results, once the governance agent node determines the identifier of the target proposal, that is, after determining the target proposal with the largest number of votes in this governance process, the target proposal can be executed.

[0082] As an example, the execution of the target proposal can be automatically performed by the smart contract that needs to be governed according to the code program, or it can also be executed by a node determined by the smart contract that needs to be governed. S403: Write the voting root and the identifier of the target proposal into the governance contract on the chain.

[0083] In a possible implementation, reference may be made to Figure 6 , Figure 6A schematic diagram of a voting governance interaction process provided in an embodiment of the present application.

[0084] The blockchain is the blockchain where the smart contract that needs to be governed is located. The blockchain contains various blocks, such as block M-1, block M, and block N. Block M is the block on the blockchain that records the start time of voting governance, and block N is the block on the blockchain that records the end time of voting governance. The governance contract can leave a trace of the entire governance process and store the state root and voting root. It is also a smart contract for on-chain arbitration when governance disputes arise. At the beginning of voting governance, the values ​​of block height M, block height N, and state root State_root can be filled into the storage slot in the governance contract, and then the governance proxy node can receive the voting message body of the external user node with governance rights, so that the governance proxy node can calculate the voting root according to formula 1. After obtaining the voting root, the governance proxy node can write the voting root into the fourth element position of the storage slot in the governance contract.

[0085] Since the values ​​of block height M, block height N, and state root State_root in the storage slot of the governance contract have not changed, only the value of the voting root in the storage slot can be updated.

[0086] For example, Contract.Storage.Vote_root=Vote_root, Contract.Storage.Vote_root represents the voting root to be filled in the storage slot of the governance contract, and the Vote_root on the right side of the equal sign is the voting root obtained by calculation, which is used to indicate that the calculated voting root is written into the storage slot of the governance contract. At the same time, before reaching block N, that is, before the end time of the voting governance, the Merkle tree can also be updated according to the latest voting message body received, and the latest voting root of the updated Merkle tree can be obtained, so that the latest voting root can be updated to the fourth element position in the storage slot to ensure the integrity and timeliness of the voting governance. It should be noted that the governance proxy node does not limit the number of updates to the voting root, and does not affect the implementation of the embodiment of the present application. In addition, after writing the voting root into the governance contract, the voting root can also be written into the smart contract that needs to be governed. Since the blockchain is the blockchain where the smart contract that needs to be governed is located, Figure 6 The voting root can be written into the blockchain, that is, the voting root is stored in the blockchain to ensure the security of the voting results.

[0087] At the same time, please refer to Figure 7 , Figure 7A schematic diagram of another voting governance interaction process provided for an embodiment of the present application, in which the identifier of the target proposal that obtains the largest number of votes in favor can also be written into the governance contract on the chain, that is, the Vote_index in the governance contract can be updated. At this time, the Vote_index is used to represent the identifier of the target proposal that obtains the largest number of votes in favor, providing a data basis for subsequent verification of voting governance and facilitating subsequent calls.

[0088] It should be noted that the root of the Merkle tree and each Merkle path can be made public to each user node with governance rights, providing data support for subsequent verification of voting governance, making it convenient for users to verify the voting governance process based on the public Merkle path, and ensuring the verifiability of voting governance. Only the root of the Merkle tree and the identifier of the target proposal are stored in the governance contract on the chain, and there is no need to store all related operations in the governance process on the chain, thereby improving governance efficiency.

[0089] In addition, after writing the identification and voting root of the target proposal that has received the most votes into the governance contract, the voting root and the identification of the target proposal can also be written into the smart contract that needs to be governed. Since the blockchain is the blockchain where the smart contract that needs to be governed is located, Figure 7 The voting root and the identifier of the target proposal can be written into the blockchain, that is, the voting root and the identifier of the target proposal can be stored in the blockchain.

[0090] The embodiment of the present application provides a blockchain voting governance method, which is applied to a governance proxy node. In the method, a voting message body of a user node with governance rights is received, and the voting message body includes the identification of the proposal voted for. Based on each received voting message body, the identification of the target proposal that has received the most votes is determined, and a Merkle tree is generated by hashing based on each received voting message body, and the root of the Merkle tree obtained by the operation is used as the voting root. The voting root and the identification of the target proposal are written into the governance contract on the chain.

[0091] It can be seen that after receiving the voting message body of the user node with governance rights, the proposal identifier with the most votes can be determined based on each voting message body, and the Merkle tree composed of each voting message body can be obtained through hash operation, so that the Merkle tree root can be used as the voting root. Therefore, only the voting root and the identifier of the target proposal can be written into the governance contract on the chain through the governance proxy node, without the need to store all related operations in the voting governance process on the chain, thereby improving governance efficiency.

[0092] If pure voting governance is adopted, such as a decentralized autonomous organization (DAO) and voting system on a public chain, DAO governance and voting tools are provided for the public-private key-based account system on the public chain, and voting rights and voting weights are allocated to users based mainly on the number of votes of users on the chain. When users vote, they only need to sign with their private keys, and there is no on-chain operation. In other words, voting and the calculation of voting results are centralized and not stored on the chain, which leads to the problems of centralization and opacity in voting governance, reducing the security of voting governance.

[0093] Therefore, see Figure 4B , Figure 4B A flowchart of another blockchain voting governance method provided in an embodiment of the present application. Figure 4B In the blockchain voting governance method, the method is applied to the governance proxy node, including:

[0094] S4011: Receive a voting message body from a user node with governance rights, where the voting message body includes the identifier of the proposal voted for.

[0095] S4022: Determine the identifier of the target proposal that has received the most votes based on the received voting message bodies, generate a Merkle tree through hash operation based on the received voting message bodies, and use the root of the Merkle tree obtained by the operation as the voting root.

[0096] S4033: Write the voting root and the identifier of the target proposal into the governance contract on the chain.

[0097] S4044: In response to the governance questioning request, obtain the questioned Merkle path.

[0098] According to the above steps, the governance proxy node only stores the voting root and the target proposal identifier in the governance contract on the chain. The governance proxy node still has the possibility of doing evil. If the effectiveness of voting governance cannot be verified, the security of the voting governance process will be reduced. Therefore, voting governance can be verified.

[0099] In one possible implementation, when a voting user finds that his or her voting path has been modified or the final counting results, including information such as weight or number of votes, are incorrect, the user can send a governance questioning request to the governance contract on the chain through the user node, i.e., the questioning node, where the governance questioning request contains the questioned Merkle path.

[0100] As an example, Req i=<Address,Vote_path,State_proof> , Req i For governance questioning requests, multiple questions within the questioning period can be distinguished by the subscript i. The governance questioning request is a tuple consisting of three elements, including the user address Address, the questioned Merkle path Vote_path, and the user's governance proof State_proof.

[0101] Therefore, the governance proxy node can obtain the questioned Merkle path based on the governance questioning request. For example, the Merkle path may be Vote_root-H(1,:)-H(1,1), and the Merkle path from the Merkle tree root to H(1,1) is the questioned Merkle path.

[0102] S4055: Query the target voting message body associated with the Merkle path according to the Merkle tree, and obtain the voting proof of the Merkle path according to the Merkle tree.

[0103] In a possible implementation, the leaf node of the questioned Merkle path can be queried from the Merkle tree, and the leaf node is used as the target voting message body. For example, Vote_body = GET_LEAF<Vote_path,Vote_root> , Vote_body is the target voting message body, that is, the target voting message body obtained by this query, GET_LEAF() is a database query function that obtains the leaf node of the Merkle path Vote_path in question from the Merkle tree corresponding to the voting root Vote_root. Figure 5 Taking the Merkle tree in as an example, we can query the leaf node with the path Vote_root-H(1,:)-H(1,1) from the corresponding Merkle tree according to the voting root Vote_root. The leaf node obtained by the query is the voting message body 1-1, and the voting message body 1-1 can be used as the target voting message body.

[0104] In addition to submitting the target voting message body to the on-chain governance contract, the governance proxy node also needs to submit the voting proof of the questioned Merkle path to the governance contract. In one possible implementation, the adjacent nodes of each node on the questioned Merkle path can be obtained from the Merkle tree, and the adjacent nodes can be used as the voting proof of the questioned Merkle path. For example, Vote_proof = GET_PROOF<Vote_path,Vote_root> , Vote_proof is the voting proof of the Merkle path obtained this time, and GET_PROOF() is a proof function for obtaining the adjacent nodes of each node on the Merkle path Vote_path that is in question from the Merkle tree corresponding to the voting root Vote_root. Figure 5Taking the Merkle tree in as an example, we can query the adjacent nodes of each node on the path Vote_root-H(1,:)-H(1,1) from the corresponding Merkle tree according to the voting root Vote_root. The adjacent node of H(1,:) is H(2,:), and the adjacent node of H(1,1) is H(1,2). Then the voting proofs of the Merkle path obtained this time are H(2,:) and H(1,2).

[0105] S4066: Submit the target voting message body and voting proof to the governance contract so that the governance contract can verify the validity of the voting governance based on the target voting message body, voting proof, voting root and the identifier of the target proposal.

[0106] After obtaining the target voting message body and voting proof, the governance proxy node can submit the target voting message body and voting proof to the governance contract on the chain. After receiving the call from the governance proxy node, the governance contract on the chain can verify the validity of the voting governance based on the target voting message body, voting proof, recorded voting root and recorded target proposal identifier.

[0107] For example, Valid2 = Validate<Vote_body,Vote_proof,Vote_root> , Valid2 is the result of the validity verification, which can be represented by true or false, Validate() is the verification function, Vote_body is the target voting message body, Vote_proof is the voting proof, and Vote_root is the voting root recorded in the governance contract. When the result of the validity verification Valid2 is true, it means that the voting root submitted by the governance proxy node is legal. However, the legality of this voting root only means that the voting message body is true, and cannot represent whether the counting result is true, so the on-chain counting can be re-performed. When the result of the validity verification Valid2 is false, it means that the voting root submitted by the governance proxy node is illegal, indicating that the voting root is invalid, and the verification of this voting governance is invalid.

[0108] At the same time, since the governance contract is also used to handle governance pledge rewards and penalties, when the governance contract verifies that this voting governance is invalid, it can send reward information to the user node that raised the governance questioning request, that is, the questioning node that raised the governance questioning request. For example, if the questioning is successful, the number of votes owned by the user node can be increased. It can also send a penalty message to the governance proxy node. For example, if the voting governance fails this time, the user node's voting message body will be stopped from being received next time. Through the reward and punishment function recorded in the governance contract, the possibility of governance proxy nodes doing evil can be effectively reduced, thereby improving the security of the governance process.

[0109] Specifically, please refer to Figure 8 , Figure 8A schematic diagram of an interactive process for verifying the effectiveness of voting governance provided in an embodiment of the present application.

[0110] Figure 8 It includes questioning nodes, which are nodes that users run outside of governance proxy nodes to actually run blockchain accounting programs, maintain blockchain world status data, and process blockchain transactions. Questioning nodes can detect the voting roots published on the chain and can make corresponding comparisons with the Merkle tree published by the governance proxy node to identify false voting and false vote counting.

[0111] When the user node, i.e. the questioning node, has an abnormal voting path or voting result, it can send a governance questioning request to the governance contract to verify the validity of the voting governance. After receiving the governance questioning request, the governance contract can provide the questioned Merkle path to the governance proxy node, and then the governance proxy node can obtain the target voting message body and voting proof based on the Merkle tree and the questioned Merkle path, and submit the target voting message body and voting proof to the governance contract, so that the governance contract can re-verify the voting root based on the recorded voting root, the identifier of the recorded target proposal, the target voting message body and the voting proof. When the voting root is verified to be legal, the votes can be re-counted to ensure the transparency and security of the governance process.

[0112] The embodiment of the present application provides a blockchain voting governance method, which is applied to a governance proxy node. In the method, a voting message body of a user node with governance rights is received, and the voting message body includes the identification of the proposal voted for. Based on each received voting message body, the identification of the target proposal that has obtained the most votes is determined, and a Merkle tree is generated by hash operation according to each received voting message body, and the root of the Merkle tree obtained by the operation is used as the voting root. The voting root and the identification of the target proposal are written into the governance contract on the chain. In response to a governance questioning request, the questioned Merkle path is obtained. According to the Merkle tree, the target voting message body associated with the Merkle path is queried, and the voting proof of the Merkle path is obtained according to the Merkle tree. The target voting message body and the voting proof are submitted to the governance contract so that the governance contract verifies the validity of the voting governance based on the identification of the target voting message body, the voting proof, the voting root and the target proposal.

[0113] It can be seen that by receiving the voting message body through the governance proxy node, and obtaining the voting root based on the voting message body, the voting root and the identifier of the target proposal are written into the governance contract on the chain, and there is no need to store all related operations in the voting governance process on the chain, thereby improving governance efficiency. In response to the governance questioning request, based on the questioned Merkel path, the target voting message body and voting proof associated with the Merkel path are obtained and submitted to the governance contract on the chain, so that the governance contract on the chain verifies the validity of the voting governance. Through on-chain storage and verification, the decentralization and transparency of governance are guaranteed, thereby improving the security of governance. By combining on-chain and off-chain methods, voting governance and verification of the effectiveness of voting governance are completed, while ensuring the decentralization and transparency of blockchain governance, governance efficiency and security are improved.

[0114] Fig. 9A A flowchart of another blockchain voting governance method provided in an embodiment of the present application. Fig. 9A In the blockchain voting governance method shown, the method is applied to the governance contract on the chain, including:

[0115] S901: Receive the voting root and target proposal identifiers submitted by the governance proxy node to the chain.

[0116] The voting root is the root of the Merkle tree generated by the governance agent node through hash operation based on the various voting message bodies received. The target proposal is the proposal that receives the most data votes, determined by the governance agent node based on the various voting message bodies received. The voting message body contains the identifier of the proposal voted for.

[0117] User votes are collected and counted through governance proxy nodes, and only the voting root and the identifier of the target proposal are recorded on the chain. Compared with the traditional pure on-chain voting governance solution, which requires users to pay a large amount of handling fees and consumes a lot of on-chain resources, this solution not only reduces the waste of on-chain resources, but also reduces governance costs and improves governance efficiency.

[0118] S902: Receive a governance questioning request from a user node, where the governance questioning request carries the Merkle path being questioned.

[0119] When a user node has doubts about voting governance, it can send a governance questioning request to the governance contract. The governance questioning request contains the Merkle path being questioned, and then the governance contract on the chain can receive the governance questioning request sent by the user node.

[0120] S903: Provide the Merkle path to the governance proxy node.

[0121] In a possible implementation, the governance challenge request also includes the address information of the user node and the user's governance proof information, namely, the user node's address Address and the user's governance proof State_proof. The user's governance proof State_proof is the information on the user node's account status at the start time of voting governance.

[0122] When the governance contract receives the governance questioning request from the user node, it can first verify whether the user node has governance rights based on the address of the user node and the user governance proof, combined with the recorded state root. For example, Valid1 = Validate (Address, State_proof, State_root), Valid1 is the verification result of verifying whether the user node has governance rights, and Validate() is the verification function. Specifically, a state root can be recalculated based on the user governance proof State_proof, the address of the user node Address, and the hash value of the account state corresponding to the start time of voting governance of other user nodes in the state tree. According to the consistency of the recalculated state root and the state root State_root recorded in the storage slot of the governance contract, verify whether the user node under the address has governance rights. When Valid1 is true, it means that the user node under the address is verified to have governance rights, and the questioned Merkel path is provided to the governance proxy node. If Valid1 is false, it means that the user node under the address is verified not to have governance rights, and the governance questioning request is determined to be invalid.

[0123] The embodiment of the present application provides a blockchain voting governance method, which is applied to the governance contract on the chain. In the method, the voting root and the identifier of the target proposal submitted by the governance proxy node to the chain are received, and then the governance questioning request of the user node is received, and the Merkle path questioned in the governance questioning request is provided to the governance proxy node. It is necessary to store only the identification of the voting root and the target proposal in the governance contract on the chain, and there is no need to store all operations in the voting governance process, thereby improving the governance efficiency. At the same time, through the governance questioning request initiated by the user node, the governance contract on the chain can verify the voting results based on the identification of the voting root and the target proposal, thereby improving the security in the governance process.

[0124] Fig. 9B A flowchart of another blockchain voting governance method provided in an embodiment of the present application. Fig. 9B In the blockchain voting governance method shown, the method is applied to the governance contract on the chain, including:

[0125] S9011: Receive the voting root and target proposal identifiers submitted by the governance proxy node to the chain.

[0126] S9022: Receive a governance questioning request from a user node, where the governance questioning request carries the Merkle path being questioned.

[0127] S9033: Provide Merkle path to governance proxy node.

[0128] S9044: Receive the target voting message body and voting proof of the Merkle path submitted by the governance agent node based on the Merkle path.

[0129] The target voting message body refers to the leaf node of the questioned Merkle path that the governance proxy node has queried based on the Merkle tree. The voting proof of the Merkle path refers to the governance proxy node obtaining the adjacent nodes of each node on the questioned Merkle path based on the Merkle tree. After the governance proxy node obtains the target voting message body and voting proof, it submits them to the governance contract on the chain, and then the governance contract can receive the target voting message body and voting proof.

[0130] S9055: Verify the validity of voting governance based on the target voting message body, voting proof, voting root and identification of the target proposal.

[0131] In one possible implementation, a voting root can be recalculated based on the target voting message body and the voting proof, and the recalculated voting root can be compared with the voting root recorded in the governance contract storage slot. If the two are consistent, the voting root submitted by the governance proxy node can be verified to be legal. If the two are inconsistent, the voting root submitted by the governance proxy node can be verified to be illegal.

[0132] When the voting root is legal, it only indicates that the voting message body is real, but cannot indicate the authenticity of the vote counting result. Therefore, the on-chain vote counting can be re-performed according to the identifier of the proposal contained in the target voting message body. For example, Vote[Vote_body.Vote_index]+=k, Vote is the mapping of the global vote weight recorded in the governance contract, Vote_body.Vote_index indicates the identifier of the proposal contained in the target voting message body, k is 1, indicating that the address of a user node has one vote, and k greater than 1 indicates the number of votes owned by the user, so the k value can be set according to the actual application.

[0133] Then, the global vote count Vote can be counted according to the voting and counting program on the smart contract chain to obtain the corresponding recount results on the blockchain. According to the recount results, the identification of the proposal with the largest number of votes can be determined. If the identification of the proposal with the largest number of votes re-determined is consistent with the identification of the target proposal recorded in the governance contract, the voting governance is verified to be valid. If the identification of the proposal with the largest number of votes re-determined is inconsistent with the identification of the target proposal recorded in the governance contract, the voting governance is verified to be invalid. Verification and recounting by the on-chain governance contract ensure that the governance proxy node cannot change the voting message body and voting results during the voting governance process, thereby improving the security of the governance process.

[0134] At the same time, when the voting root is verified to be illegal, the voting governance is also verified to be invalid. After the voting governance is verified to be invalid, reward information can be sent to the user node that raised the governance questioning request, and a penalty message can be sent to the governance proxy node. Through the reward and punishment function recorded in the governance contract, the possibility of the governance proxy node doing evil can be effectively reduced, thereby improving the security of the governance process.

[0135] The embodiment of the present application provides a blockchain voting governance method, which is applied to the governance contract on the chain. In the method, the voting root and the identifier of the target proposal submitted by the governance proxy node to the chain are received, and then the governance questioning request of the user node is received, and the governance questioning request carries the Merkle path being questioned. The Merkle path is provided to the governance proxy node, and the target voting message body and the voting proof of the Merkle path submitted by the governance proxy node based on the Merkle path are received. Finally, the validity of the voting governance can be verified based on the target voting message body, the voting proof, the voting root and the identifier of the target proposal. It can be seen that in this scheme, the governance proxy node cannot modify the user's vote itself and its counting results by questioning the user node in the on-chain governance contract and verifying it through the governance contract. Through economic motivation and game, combined with the verification of the on-chain governance contract, the security of the governance process is improved.

[0136] Based on the blockchain voting governance method provided in the previous embodiment, this application also provides a blockchain voting governance system. Fig.10 To explain, Fig.10 A schematic diagram of the structure of a blockchain voting governance system provided in an embodiment of the present application. Fig.10 The blockchain voting governance system shown includes: multiple user nodes 1001 with governance rights, governance agent nodes 1002, and a governance contract 1003 on the blockchain.

[0137] The user node 1001 is used to send a voting message body to the governance proxy node 1002, where the voting message body includes an identifier of a proposal voted for;

[0138] The governance proxy node 1002 is used to receive the voting message body of the user node 1001 with governance rights; determine the identifier of the target proposal that has received the most votes based on each received voting message body, generate a Merkle tree through hash operation based on each received voting message body, and use the root of the Merkle tree obtained by operation as the voting root; write the voting root and the identifier of the target proposal into the governance contract 1003;

[0139] Governance contract 1003, used to receive the voting root and target proposal identifiers submitted by governance proxy node 1002 to the chain;

[0140] The user node 1001 is also used to send a governance questioning request to the governance contract 1003 when there is doubt about the voting governance, and the governance questioning request carries the Merkle path being questioned;

[0141] The governance contract 1003 is also used to provide the questioned Merkle path to the governance proxy node 1002.

[0142] Optionally, the governance proxy node 1002 is further used to obtain the questioned Merkel path, query the target voting message body associated with the questioned Merkel path according to the Merkel tree, and obtain the voting certificate of the questioned Merkel path according to the Merkel tree; submit the target voting message body and the voting certificate to the governance contract 1003;

[0143] The governance contract 1003 is also used to verify the validity of the voting governance based on the target voting message body, the voting proof, the voting root and the identifier of the target proposal.

[0144] Optionally, the governance agent node 1002 is also used to obtain the questioned Merkle path, query the leaf nodes of the Merkle path from the Merkle tree, and use the leaf nodes as the target voting message body; obtain the adjacent nodes of each node on the Merkle path from the Merkle tree, and use the adjacent nodes as voting proofs for the Merkle path.

[0145] Optionally, the governance proxy node 1002 is also used to insert a storage slot into the governance contract at the start of voting governance, and the first element position of the storage slot is filled with the identifier of the starting governance block, the second element position is filled with the identifier of the ending governance block, the third element position is filled with the state root of the state tree at the start time of voting governance, and the fourth element position is preset to be empty and used to fill in the voting root; the starting governance block is the block on the blockchain that records the start time of voting governance, and the ending governance block is the block on the blockchain that records the end time of voting governance; writing the voting root into the governance contract on the chain includes: writing the voting root into the fourth element position of the storage slot.

[0146] Optionally, the governance proxy node 1002 is also used to update the Merkle tree according to the latest voting message body received before the voting governance end time, obtain the latest voting root of the updated Merkle tree; and update the latest voting root to the fourth element position.

[0147] Optionally, the governance proxy node 1002 is also used to disclose the root of the Merkle tree and each Merkle path to each user node with governance rights.

[0148] Optionally, the governance proxy node 1002 is also used to receive a penalty message against the node after the governance contract verifies that the voting governance is invalid.

[0149] Optionally, the governance question request also carries the address information of the user node and the user's governance rights proof information; the user's governance rights proof information is the information provided by the user node to indicate the account status at the start time of voting governance. The governance contract 1003 is also used to recalculate the state root according to the user's governance rights proof information, the address information of the user node and the account status of other user nodes in the state tree at the start time of voting governance; based on the consistency of the recalculated state root and the pre-stored state root, verify whether the user node of the address information has governance rights; the pre-stored state root is the state root of the state tree at the start time of voting governance; if the user node that verifies the address information has governance rights, the Merkel path is provided to the governance proxy node; if the user node that verifies the address information does not have governance rights, the governance question request is determined to be invalid.

[0150] Optionally, the governance contract 1003 is also used to recalculate the voting root according to the target voting message body and the voting certificate; compare the recalculated voting root with the voting root submitted by the governance proxy node, and if they are consistent, verify that the voting root submitted by the governance proxy node is legal; if they are inconsistent, verify that the voting root submitted by the governance proxy node is illegal; if the voting root is verified to be legal, recount the votes according to the identifier of the proposal included in the target voting message body, and determine the identifier of the proposal with the largest number of votes in favor according to the recount result; if the identifier of the proposal with the largest number of votes in favor determined according to the recount result is consistent with the identifier of the target proposal, verify that the voting governance is valid; if the identifier of the proposal with the largest number of votes in favor determined according to the recount result is inconsistent with the identifier of the target proposal, verify that the voting governance is invalid; if the voting root is verified to be illegal, verify that the voting governance is invalid.

[0151] Optionally, the governance contract 1003 is also used to send a reward message to the user node that raised the governance question request, and to send a penalty message to the governance agent node.

[0152] An embodiment of the present application provides a blockchain voting governance device, which may be a server. Fig.11 : This is a schematic diagram of a server structure provided in an embodiment of the present application. The server 900 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 922 (for example, one or more processors) and a memory 932, and one or more storage media 930 (for example, one or more mass storage devices) storing application programs 942 or data 944. Among them, the memory 932 and the storage medium 930 can be short-term storage or permanent storage. The program stored in the storage medium 930 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Furthermore, the central processing unit 922 can be configured to communicate with the storage medium 930 and execute a series of instruction operations in the storage medium 930 on the server 900.

[0153] The server 900 may also include one or more power supplies 926 , one or more wired or wireless network interfaces 950 , one or more input and output interfaces 958 , and / or one or more operating systems 941 .

[0154] The CPU 922 is used to execute the following steps:

[0155] Receive a voting message body from a user node with governance rights, where the voting message body includes an identifier of a proposal voted for;

[0156] Determine the identifier of the target proposal that has received the most votes based on each received voting message body, generate a Merkle tree through hash operation based on each received voting message body, and use the root of the Merkle tree obtained by the operation as the voting root;

[0157] Write the voting root and the identifier of the target proposal into the governance contract on the chain.

[0158] Alternatively, receiving the voting root and the identifier of the target proposal submitted by the governance proxy node to the chain; the voting root is the root of the Merkle tree generated by the governance proxy node through hash operation according to each received voting message body, and the target proposal is the proposal that obtains the most votes in favor determined by the governance proxy node based on each received voting message body; the voting message body includes the identifier of the proposal voted in favor of;

[0159] Receiving a governance challenge request from a user node, wherein the governance challenge request carries a Merkle path being challenged;

[0160] Provide the Merkle path to the governance proxy node.

[0161] The present application embodiment also provides another blockchain voting governance device, which can be a terminal device. Fig.12 For the sake of convenience, only the parts related to the embodiments of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiments of the present application. Take the terminal device as a mobile phone as an example:

[0162] Fig.12 The block diagram shows a partial structure of a mobile phone provided in an embodiment of the present application. Fig.12 The mobile phone includes: a radio frequency (RF) circuit 1010, a memory 1020, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, a wireless fidelity (WiFi) module 1070, a processor 1080, and a power supply 1090. Those skilled in the art can understand that Fig.12 The mobile phone structure shown in the figure does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0163] Combine the following Fig.12 A detailed introduction to the various components of the mobile phone:

[0164] The RF circuit 1010 can be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information of the base station, it is sent to the processor 1080 for processing; in addition, the designed uplink data is sent to the base station. Generally, the RF circuit 1010 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (full name: LowNoiseAmplifier, English abbreviation: LNA), a duplexer, etc. In addition, the RF circuit 1010 can also communicate with the network and other devices through wireless communication. The above-mentioned wireless communications may use any communication standard or protocol, including but not limited to Global System of Mobile communications (Global System of Mobile communication, English abbreviation: GSM), General Packet Radio Service (General Packet Radio Service, GPRS), Code Division Multiple Access (Code Division Multiple Access, English abbreviation: CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (Long Term Evolution, English abbreviation: LTE), e-mail, Short Messaging Service (SMS), etc.

[0165] The memory 1020 can be used to store software programs and modules. The processor 1080 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 1020. The memory 1020 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 1020 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0166] The input unit 1030 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the mobile phone. Specifically, the input unit 1030 may include a touch panel 1031 and other input devices 1032. The touch panel 1031, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 1031 or near the touch panel 1031 using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch panel 1031 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 1080, and can receive and execute commands sent by the processor 1080. In addition, the touch panel 1031 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 1031, the input unit 1030 may further include other input devices 1032. Specifically, the other input devices 1032 may include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

[0167] The display unit 1040 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 1040 may include a display panel 1041. Optionally, the display panel 1041 may be configured in the form of a liquid crystal display (full name in English: Liquid Crystal Display, English abbreviation: LCD), an organic light-emitting diode (full name in English: Organic Light-Emitting Diode, English abbreviation: OLED), etc. Further, the touch panel 1031 may cover the display panel 1041. When the touch panel 1031 detects a touch operation on or near it, it is transmitted to the processor 1080 to determine the type of touch event. Subsequently, the processor 1080 provides a corresponding visual output on the display panel 1041 according to the type of touch event. Although in Fig.12 In the embodiment, the touch panel 1031 and the display panel 1041 are used as two independent components to realize the input and output functions of the mobile phone, but in some embodiments, the touch panel 1031 and the display panel 1041 can be integrated to realize the input and output functions of the mobile phone.

[0168] The mobile phone may also include at least one sensor 1050, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 1041 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 1041 and / or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

[0169] The audio circuit 1060, the speaker 1061, and the microphone 1062 can provide an audio interface between the user and the mobile phone. The audio circuit 1060 can transmit the received audio data to the speaker 1061 after converting the received audio data into an electrical signal, which is converted into a sound signal for output; on the other hand, the microphone 1062 converts the collected sound signal into an electrical signal, which is received by the audio circuit 1060 and converted into audio data, and then the audio data is output to the processor 1080 for processing, and then sent to another mobile phone through the RF circuit 1010, or the audio data is output to the memory 1020 for further processing.

[0170] WiFi is a short-range wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages and access streaming media through the WiFi module 1070. It provides users with wireless broadband Internet access. Fig.12 A WiFi module 1070 is shown, but it is understandable that it is not an essential component of the mobile phone and can be omitted as needed without changing the essence of the invention.

[0171] The processor 1080 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. By running or executing software programs and / or modules stored in the memory 1020, and calling data stored in the memory 1020, it executes various functions of the mobile phone and processes data, thereby collecting overall data and information of the mobile phone. Optionally, the processor 1080 may include one or more processing units; preferably, the processor 1080 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 1080.

[0172] The mobile phone also includes a power supply 1090 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 1080 through a power management system, so that the power management system can manage functions such as charging, discharging, and power consumption.

[0173] Although not shown, the mobile phone may also include a camera, a Bluetooth module, etc., which will not be described in detail here.

[0174] In the embodiment of the present application, the processor 1080 included in the mobile phone also has the following functions:

[0175] Receive a voting message body from a user node with governance rights, where the voting message body includes an identifier of a proposal voted for;

[0176] Determine the identifier of the target proposal that has received the most votes based on each received voting message body, generate a Merkle tree through hash operation based on each received voting message body, and use the root of the Merkle tree obtained by the operation as the voting root;

[0177] Write the voting root and the identifier of the target proposal into the governance contract on the chain.

[0178] Alternatively, receiving the voting root and the identifier of the target proposal submitted by the governance proxy node to the chain; the voting root is the root of the Merkle tree generated by the governance proxy node through hash operation according to each received voting message body, and the target proposal is the proposal that obtains the most votes in favor determined by the governance proxy node based on each received voting message body; the voting message body includes the identifier of the proposal voted in favor of;

[0179] Receiving a governance challenge request from a user node, wherein the governance challenge request carries a Merkle path being challenged;

[0180] Provide the Merkle path to the governance proxy node.

[0181] An embodiment of the present application also provides a computer-readable storage medium for storing a computer program. When the computer program is run on a blockchain voting governance device, the blockchain voting governance device executes any one of the implementation methods of a blockchain voting governance method described in the aforementioned embodiments.

[0182] An embodiment of the present application also provides a computer program product including a computer program, which, when executed on a blockchain voting governance device, enables the blockchain voting governance device to execute any one of the implementation methods of a blockchain voting governance method described in the aforementioned embodiments.

[0183] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems and devices described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0184] In the several embodiments provided in the present application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are only schematic. For example, the division of the system is only a logical function division. There may be other division methods in actual implementation, such as multiple systems can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0185] The systems described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0186] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0187] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (full name in English: Read-Only Memory, English abbreviation: ROM), random access memory (full name in English: Random Access Memory, English abbreviation: RAM), disk or optical disk and other media that can store computer programs.

[0188] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A blockchain voting governance method, characterized in that: Applied to a governance proxy node, the method includes: Receive a voting message body from a user node with governance rights, where the voting message body includes an identifier of a proposal voted for; Determine the identifier of the target proposal that has received the most votes based on each received voting message body, generate a Merkle tree through hash operation based on each received voting message body, and use the root of the Merkle tree obtained by the operation as the voting root; Write the voting root and the identifier of the target proposal into the governance contract on the chain.

2. The method according to claim 1, characterized in that Also includes: Responding to a governance challenge request, obtaining the Merkle path being challenged; Querying a target voting message body associated with the Merkle path according to the Merkle tree, and obtaining a voting certificate for the Merkle path according to the Merkle tree; Submit the target voting message body and the voting proof to the governance contract so that the governance contract verifies the validity of the voting governance based on the target voting message body, the voting proof, the voting root and the identifier of the target proposal.

3. The method according to claim 2, characterized in that The querying of the target voting message body associated with the Merkle path according to the Merkle tree, and obtaining the voting certificate of the Merkle path according to the Merkle tree, includes: Query the leaf node of the Merkle path from the Merkle tree, and use the leaf node as the target voting message body; The adjacent nodes of each node on the Merkle path are obtained from the Merkle tree, and the adjacent nodes are used as voting proofs of the Merkle path.

4. The method according to claim 1, characterized in that: Also includes: At the beginning of voting governance, a storage slot is inserted into the governance contract, the first element position of the storage slot is filled with the identifier of the starting governance block, the second element position is filled with the identifier of the ending governance block, the third element position is filled with the state root of the state tree at the start time of voting governance, and the fourth element position is preset to be empty and used to fill in the voting root; the starting governance block is the block on the blockchain that records the start time of voting governance, and the ending governance block is the block on the blockchain that records the end time of voting governance; Writing the voting root into the governance contract on the chain includes: writing the voting root into the fourth element position of the storage slot.

5. The method according to claim 4, characterized in that Before reaching the end time of voting governance, the method further includes: According to the received latest voting message body, the Merkle tree is updated to obtain the latest voting root of the updated Merkle tree; Update the latest voting root to the fourth element position.

6. The method according to claim 1, characterized in that Also includes: The root of the Merkle tree and each Merkle path are disclosed to each user node with governance rights.

7. The method according to any one of claims 1 to 6, characterized in that Also includes: After the governance contract verifies that the voting governance is invalid, a penalty message for this node is received.

8. A blockchain voting governance method, characterized in that: Applied to the governance contract on the chain, the method includes: Receive the voting root and the identifier of the target proposal submitted by the governance proxy node to the chain; the voting root is the root of the Merkle tree generated by the governance proxy node through hash operation according to each received voting message body, and the target proposal is the proposal that has obtained the most votes supported by the governance proxy node based on each received voting message body; the voting message body includes the identifier of the proposal voted for; Receiving a governance challenge request from a user node, wherein the governance challenge request carries a Merkle path being challenged; Provide the Merkle path to the governance proxy node.

9. The method according to claim 8, characterized in that Also includes: Receive the target voting message body submitted by the governance proxy node based on the Merkle path and the voting proof of the Merkle path; The target voting message body is the voting message body associated with the Merkle path queried by the governance proxy node according to the Merkle tree, and the voting proof of the Merkle path is obtained by the governance proxy node according to the Merkle tree; The validity of the voting governance is verified according to the target voting message body, the voting proof, the voting root and the identifier of the target proposal.

10. The method according to claim 9, characterized in that The governance challenge request also carries the address information of the user node and the user governance right certification information; the user governance right certification information is information provided by the user node to indicate the account status at the start time of voting governance; Providing the Merkle path to the governance proxy node includes: Recalculate the state root based on the user governance right certification information, the address information of the user node, and the account status of other user nodes in the state tree at the start time of voting governance; Verify whether the user node of the address information has governance rights based on the consistency between the recalculated state root and the pre-stored state root; the pre-stored state root is the state root of the state tree at the start time of voting governance; If the user node that verifies the address information has governance rights, the Merkle path is provided to the governance proxy node; if the user node that verifies the address information does not have governance rights, the governance questioning request is determined to be invalid.

11. The method according to claim 10, characterized in that The verifying the validity of the voting governance according to the target voting message body, the voting proof, the voting root and the identifier of the target proposal includes: Recalculate the voting root according to the target voting message body and the voting proof; Compare the recalculated voting root with the voting root submitted by the governance proxy node. If they are consistent, verify that the voting root submitted by the governance proxy node is legal. If they are inconsistent, verify that the voting root submitted by the governance proxy node is illegal. If the voting root is verified to be legal, the votes are recounted according to the identifier of the proposal included in the target voting message body, and the identifier of the proposal with the largest number of votes is determined according to the recount result; if the identifier of the proposal with the largest number of votes determined according to the recount result is consistent with the identifier of the target proposal, the voting governance is verified to be valid; if the identifier of the proposal with the largest number of votes determined according to the recount result is inconsistent with the identifier of the target proposal, the voting governance is verified to be invalid; If the voting root is verified to be illegal, the voting governance is invalid.

12. The method according to claim 11, characterized in that After verifying that the voting governance is invalid, the method further includes: A reward message is sent to the user node that raised the governance challenge request, and a penalty message is sent to the governance proxy node.

13. A blockchain voting governance system, characterized in that: include: Multiple user nodes with governance rights, governance contracts on the blockchain, and governance proxy nodes; The user node is used to send a voting message body to the governance proxy node, where the voting message body includes an identifier of a proposal voted for; The governance proxy node is used to receive voting message bodies from user nodes with governance rights; determine the identifier of the target proposal that has received the most votes based on each received voting message body, generate a Merkle tree through hash operation based on each received voting message body, and use the root of the Merkle tree obtained by operation as the voting root; Writing the voting root and the identifier of the target proposal into the governance contract; The governance contract is used to receive the voting root and target proposal identifiers submitted by the governance proxy node to the chain; The user node is further used to send a governance questioning request to the governance contract when there is doubt about the voting governance, and the governance questioning request carries the Merkle path being questioned; The governance contract is also used to provide the questioned Merkle path to the governance proxy node.

14. The system according to claim 13, characterized in that The governance proxy node is further used to obtain the questioned Merkle path, query the target voting message body associated with the questioned Merkle path according to the Merkle tree, and obtain the voting certificate of the questioned Merkle path according to the Merkle tree; submit the target voting message body and the voting certificate to the governance contract; The governance contract is also used to verify the validity of voting governance based on the target voting message body, the voting proof, the voting root and the identifier of the target proposal.

15. A blockchain voting governance device, characterized in that: The device comprises a processor and a memory: The memory is used to store a computer program and transmit the computer program to the processor; The processor is configured to execute the steps of the method of any one of claims 1 to 7 or the steps of the method of any one of claims 8 to 12 according to the instructions in the computer program.

Images