VDF-based on-chain voting method, device and storage medium

Abstract

The present application discloses a VDF-based on-chain voting method, device, and storage medium. The method includes: obtaining a first parameter set corresponding to a preset VDF algorithm; obtaining a target edit request initiated by a target node; writing the target edit request into a voting initiation contract through the target node, and determining the target VDF calculation count corresponding to the target edit request through the voting initiation contract; determining the nodes in the initial blockchain that have voting intentions to obtain m nodes; obtaining the voting transactions of each of the m nodes through the voting contract to obtain m voting transactions; determining whether the target edit request is passed based on the m voting transactions; and when the target edit request is passed, editing the initial blockchain based on the preset blockchain editing algorithm and the target edit request to obtain a target blockchain. By adopting the embodiments of the present application, the security of the blockchain voting process in an unregulated scenario can be ensured.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to a VDF-based on-chain voting method, device, and storage medium. Background Art

[0002] The Chameleon Hash (CH) function is currently the most commonly used algorithm for implementing editable blockchains. Protecting the trapdoor TD is crucial to the Chameleon Hash algorithm; controlling TD grants access to blockchain editing. Common protection methods involve multi-party custody, distribution, and replacement through trusted authorities. However, these approaches rely on reliable third-party institutions and are not applicable in unsupervised scenarios (e.g., public blockchains).

[0003] Therefore, in an unregulated scenario, how to ensure the security of the blockchain voting process needs to be urgently addressed. Summary of the Invention

[0004] The embodiments of the present application provide a VDF-based on-chain voting method, device, and storage medium, which can ensure the security of the blockchain voting process in an unregulated scenario.

[0005] In a first aspect, embodiments of the present application provide a VDF-based on-chain voting method, which is applied to an initial blockchain. Each node in the initial blockchain includes a voting initiation contract and a voting contract. The method includes:

[0006] Obtain a first parameter set corresponding to a preset VDF algorithm;

[0007] Obtain a target edit request txeditreq initiated by a target node; the target node is any node in the initial blockchain;

[0008] The target edit request txeditreq is written into the voting initiation contract through the target node, and the target VDF calculation times Teditreq corresponding to the target edit request txeditreq is determined through the voting initiation contract;

[0009] Determine nodes in the initial blockchain that have voting intentions, and obtain m nodes; m is a natural number;

[0010] Obtaining, through the voting contract, voting transactions of each of the m nodes to obtain m voting transactions; each voting transaction includes a voting result and a VDF calculation result; the VDF calculation result is a result obtained by performing VDF calculations on the m nodes based on the first parameter set;

[0011] Determine whether the target edit request txeditreq is passed according to the m voting transactions;

[0012] When the target edit request txeditreq is voted through, the initial blockchain is edited based on the preset blockchain editing algorithm and the target edit request txeditreq to obtain the target blockchain.

[0013] In a second aspect, an embodiment of the present application provides a VDF-based on-chain voting device, which is applied to an initial blockchain. Each node in the initial blockchain includes a voting initiation contract and a voting contract. The device includes: an acquisition unit, a voting unit, and an editing unit, wherein:

[0014] The acquisition unit is configured to acquire a first parameter set corresponding to a preset VDF algorithm; acquire a target edit request txeditreq initiated by a target node; the target node is any node in the initial blockchain;

[0015] The voting unit is configured to write the target edit request txeditreq into the voting initiation contract through the target node, and determine the target VDF calculation times Teditreq corresponding to the target edit request txeditreq through the voting initiation contract; determine the nodes in the initial blockchain that have voting intentions, and obtain m nodes; m is a natural number; obtain the voting transaction of each of the m nodes through the voting contract, and obtain m voting transactions; each voting transaction includes a voting result and a VDF calculation result; the VDF calculation result is the result obtained by the nodes in the m nodes performing VDF calculation based on the first parameter set; determine whether the target edit request txeditreq is voted through based on the m voting transactions;

[0016] The editing unit is configured to edit the initial blockchain based on a preset blockchain editing algorithm and the target editing request txeditreq to obtain a target blockchain when the target editing request txeditreq is voted through.

[0017] In a third aspect, an embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program for electronic data exchange, wherein the computer program enables a computer to execute some or all of the steps described in the first aspect of the embodiment of the present application.

[0018] In a fourth aspect, an embodiment of the present application provides an electronic device comprising a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the processor, and the program comprises instructions for executing the steps in the first aspect of the embodiment of the present application.

[0019] In a fifth aspect, embodiments of the present application provide a computer program product, wherein the computer program product includes a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a computer to perform some or all of the steps described in the first aspect of the embodiments of the present application. The computer program product may be a software installation package.

[0020] It can be seen that the VDF-based on-chain voting method provided in the embodiment of the present application obtains the first parameter set of the preset VDF algorithm. When the blockchain needs to edit the vote, each node in the blockchain performs VDF calculation and votes according to the first parameter set to obtain the VDF calculation result and the voting result. The voting result and the VDF calculation result are interrelated and verifiable. When verifying the voting transaction (that is, the VDF calculation result and the voting result), not only can it be checked whether the voting result itself complies with the rules, but the authenticity of the voting transaction can also be judged by verifying the VDF calculation result. In this way, by performing multiple verifications on the voting transaction, malicious nodes can be effectively prevented from submitting false votes, and without relying on a reliable third party, the security of the blockchain voting process in an unregulated scenario can be ensured. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background technology, the drawings required for use in the embodiments of the present application or the background technology will be described below.

[0022] Figure 1 This is a flowchart of a VDF-based on-chain voting method provided in an embodiment of the present application;

[0023] Figure 2 This is a flowchart of a blockchain editing process provided by an embodiment of the present application;

[0024] Figure 3 This is a structural diagram of the functional units of a VDF-based on-chain voting device provided in an embodiment of the present application;

[0025] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0027] The terms "first," "second," and the like in the specification and claims of this application and the accompanying drawings are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including," "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0028] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0029] The electronic devices described in the embodiments of the present application may include smart phones (such as Android phones, iOS phones, Windows Phone phones, etc.), tablet computers, PDAs, laptops, video matrices, monitoring platforms, mobile Internet devices (MIDs) or wearable devices, etc. The above are only examples and not exhaustive, including but not limited to the above devices. Of course, the above electronic devices can also be servers, for example, cloud servers.

[0030] The following is an explanation of some professional terms involved in this application:

[0031] A Verifiable Delay Function (VDF) is a cryptographic primitive whose computation requires a relatively fixed amount of time, determined by the algorithm's design and parameters rather than the performance of the computing device. Furthermore, its results are verifiable, and the verification time is significantly shorter than the computation time. VDFs are a tool for adding stable delays to distributed computing, providing a reliable "proof of the passage of time."

[0032] Blockchain editing algorithm: An algorithm used to modify the data structure of a blockchain, such as the Chameleon hash algorithm. Blockchains are generally designed to be tamper-proof, but in certain situations, such as when errors need to be corrected, smart contracts need to be updated, or systems need to be upgraded, a secure and reliable algorithm is needed to edit the blockchain.

[0033] Chameleon Hash (CH) is a special hash function that allows collision generation of hash values ​​when a specific trapdoor (trapdoor, td) is known. This means finding another input that results in the same hash value. Without the trapdoor, CH behaves like a normal hash function, making it difficult to find a collision. Therefore, only someone who knows the trapdoor td can modify blockchain data without destroying the hash value or the chain structure.

[0034] See also Figure 1 , Figure 1 This is a flowchart of a VDF-based on-chain voting method provided in an embodiment of the present application, which is applied to an initial blockchain. Each node in the initial blockchain includes a voting initiation contract and a voting contract. The method includes:

[0035] S101. Obtain a first parameter set corresponding to a preset VDF algorithm.

[0036] In an embodiment of the present application, the preset VDF algorithm can be preset or defaulted in advance; each node in the initial blockchain can also include a verification chain contract, wherein the voting initiation contract is mainly responsible for receiving and managing voting requests, the voting contract is used to record voting transactions of different nodes, and the verification chain contract is mainly responsible for the final verification of the voting results, for example, checking whether the voting nodes are legal, whether the number of votes reaches the statutory number, whether the voting results have been correctly verified by VDF calculation, etc. Only voting results that have passed the verification can be considered valid votes.

[0037] In a specific embodiment, a technical document of a preset VDF algorithm can be obtained, and a first parameter set can be obtained from the technical document. For example, the first parameter set may include at least one of the following: a VDF formula, a VDF proof algorithm, a VDF calculation parameter, etc., which are not limited here. Assuming that the preset VDF algorithm uses a repeated square method as the VDF formula, the VDF proof algorithm can be at least one of the following: an integer N multiplication group based on Euler function, Boneh interactive verification, a Wislowski verification protocol, etc., which are not limited here; the VDF calculation parameters can be set manually or preset in advance.

[0038] The repeating square method is as follows:

[0039]

[0040] Here, x is the input value of the VDF formula; T represents the number of repeated squaring operations; N is a modulus, which serves as the modulus during the calculation process; and y is the output value of the VDF formula, which is the result obtained after T repeated squaring operations, modulo N. The above formula means: square the input x, square the result again T times (a total time τ), and finally take the result modulo N. The repeated squaring cannot be parallelized, and the result is not known until the last calculation. Therefore, the time consumption and uniqueness requirements of the VDF algorithm are met. Generally speaking, the larger the value of T, the more difficult the VDF problem is, and the longer the average calculation time.

[0041] It should be noted that the blockchain involved in this application does not have any regulatory nodes or authoritative bodies, that is, the blockchain is an unregulated blockchain. The status and permissions of each node in the blockchain are consistent. Without loss of generality, all nodes participating in edit voting have read and write permissions on the blockchain. The blockchain network supports smart contracts, and the blockchain's block frequency must be relatively fixed. Of course, the VDF-based on-chain voting method provided in the embodiments of this application can also be applied to regulated blockchains.

[0042] S102. Obtain a target edit request txeditreq initiated by a target node; the target node is any node in the initial blockchain.

[0043] In an embodiment of the present application, any node in the initial blockchain can initiate an edit request for any transaction in the historical block, and the node that initiates the edit request is recorded as the target node, and the target node generates a target edit request txeditreq. Specifically, the editing intention and detailed information of the target node can be obtained first, and data that conforms to the request format of the voting initiation contract can be generated according to the editing intention and detailed information to obtain the target edit request txeditreq. For example, the request format can be "request type (edit_type) + edit object identifier (target_id) + new content (new_content)" and so on.

[0044] S103. Write the target edit request txeditreq into the voting initiation contract through the target node, and determine the target VDF calculation times Teditreq corresponding to the target edit request txeditreq through the voting initiation contract.

[0045] In an embodiment of the present application, the target edit request txeditreq can be written into the voting initiation contract through the target node and made public on the chain so that other nodes can access and view it. Then, the target VDF calculation times Teditreq corresponding to the target edit request txeditreq can be determined through the voting initiation contract.

[0046] Optionally, in step S103, the target edit request txeditreq includes: the old transaction tx, the new transaction tx', the old transaction block B where the old transaction tx is located, and the block height BH to be edited of the old transaction block B. B The process of initiating the contract through voting to determine the target VDF calculation times Teditreq corresponding to the target edit request txeditreq includes:

[0047] A1. Obtain the average block frequency t of the initial blockchain;

[0048] A2. Obtain average computing performance parameters of the hardware devices corresponding to the initial blockchain;

[0049] A3. Determine the basic number of calculations Tbase based on the average block generation frequency t and the average calculation performance parameter;

[0050] A4. Determine the current block height of the target node.

[0051] A5. Estimate the first number of calculations Tmax required from writing the target edit request txeditreq into the voting initiation contract to the end of the voting;

[0052] A6, according to the base calculation times Tbase, the current block height The first calculation times Tmax, the height of the block to be edited BH B The target VDF calculation times Teditreq is determined by the preset times calculation formula.

[0053] In the embodiment of the present application, the average computing performance parameter may include at least one of the following: the clock frequency of the central processing unit, the number of cores of the central processing unit, the computing benchmark score, the number of floating-point operations per second, etc., which are not limited here.

[0054] In a specific embodiment, the average block frequency t of the initial blockchain can be obtained first. Specifically, the initial blockchain type of the initial blockchain can be obtained, and the target blockchain browser corresponding to the initial blockchain type can be determined. The mapping relationship between the preset blockchain type and the blockchain browser can be pre-stored, and the target blockchain browser corresponding to the initial blockchain type is determined based on the mapping relationship. The initial blockchain is monitored through the target blockchain browser to obtain the generation timestamp of each block in the initial blockchain, and the difference between the generation times of adjacent blocks is calculated, and then the average block frequency t within a period of time is calculated. For example, if the generation times of 10 blocks within a certain period of time are t1, t2, ..., t10, respectively, then the average block frequency t=9 / (t10-t1).

[0055] Next, the average computing performance parameters of the hardware devices corresponding to the initial blockchain can be obtained. Specifically, the average computing performance parameter can be the number of floating-point operations per second. The device running on each node in the initial blockchain can be determined first, and multiple devices can be obtained. The number of floating-point operations per second of each device in the multiple devices can be determined to obtain multiple floating-point operations per second. The average number of floating-point operations per second of these multiple floating-point operations per second is calculated, which is the average computing performance parameter. Next, the basic calculation number Tbase can be determined according to the average block frequency t and the average computing performance parameter. Specifically, the average block time of the initial blockchain can be determined according to the average block frequency t. For example, assuming that the average block frequency t is 10 blocks per minute, the average block time is the inverse of the average block frequency t, that is, 10 seconds per block. The time for calculating a VDF formula can be estimated according to the average computing performance parameter to obtain the single time. The basic calculation number Tbase is calculated according to the single time and the average block time. The specific calculation formula is as follows:

[0056] Tbase = (average block generation time + preset time) / single time;

[0057] The preset duration is preset or defaulted in advance. It is used to ensure that the time it takes for the nodes in the initial blockchain to solve the VDF formula once is slightly longer than the average block generation time. The basic calculation times Tbase can be obtained according to the above formula. Then, the current block height of the target node can be obtained through the target blockchain browser. Then, we can estimate the first number of calculations Tmax required from the target edit request txeditreq being written into the voting initiation contract to the end of the voting; then, we can estimate the first number of calculations Tmax required from the target edit request txeditreq being written into the voting initiation contract to the end of the voting; The first calculation times Tmax, the height of the block to be edited BH B The target VDF calculation times Teditreq is determined by the preset calculation formula. The preset calculation formula is as follows:

[0058]

[0059] The function of the preset times calculation formula in this application is: to edit older transactions, you need to provide a longer calculation times as proof of time passage. Assuming Tbase = 10000, BH B =300, Tmax=10 10 According to the above formula, we can get Teditreq=2*10 9 .

[0060] It should be explained that since there are many VDF algorithms and they are not limited to the continuous square method in the embodiment of this application, there are many forms of calculation formulas for the preset number of times that are monotonically increasing and proportional. The calculation formulas for the preset number of times listed in the embodiment of this application are not necessarily optimal, but in any case, the calculation formulas for the preset number of times should satisfy the following conditions: as the height difference between the current block height and the edited block height gradually increases, the number of VDFs that need to be calculated should gradually increase and approach Tmax, and this growth rate should be as proportional as possible to the growth rate of the height difference. In extreme cases, Teditreq = Tmax, that is, the VDF calculation time is equal to the voting time. In this way, all nodes that intend to participate in transaction editing must immediately express their opinions and start voting as soon as they hear the vote is initiated, otherwise they will not be able to complete the calculation within the specified voting time.

[0061] In this way, by obtaining the average block frequency of the initial blockchain and the corresponding average computing performance parameters of the hardware equipment, we can have a more accurate grasp of the basic computing resource requirements of the blockchain system. Combining the two to determine the basic number of calculations is like doing a "physical examination" for the basic operation of the blockchain system. We can know the basic amount of computing that the system can complete under normal circumstances, which helps to rationally plan hardware resources and avoid resource waste or shortage.

[0062] Optionally, in step A5, estimating the first number of calculations Tmax required from writing the target edit request txeditreq into the voting initiation contract to the end of voting includes:

[0063] B1. Determine the target voting duration corresponding to the target edit request txeditreq;

[0064] B2. Determine a first calculation duration based on the target voting duration and the average block generation frequency t;

[0065] B3. Determine the first calculation times Tmax according to the preset VDF algorithm and the first calculation duration.

[0066] In an embodiment of the present application, the target voting duration corresponding to the target editing request txeditreq can be determined. Specifically, the target editing type of the target editing request txeditreq can be obtained, and the target voting duration can be determined based on the target editing type. For example, the mapping relationship between the preset editing type and the voting duration can be pre-stored, and the target voting duration corresponding to the target editing type can be determined based on the mapping relationship; the target editing type can include one of the following: transaction content editing type, smart contract editing type, blockchain structure editing type, etc., which are not limited here.

[0067] Next, the first calculation duration can be determined based on the target voting duration and the block frequency t. Specifically, the average block duration can be determined based on the block frequency t. Then, the first calculation duration can be determined based on the target voting duration and the average block duration. The specific calculation formula is as follows:

[0068] First calculation time = target voting time - average block time;

[0069] The first calculation duration can be obtained according to the above formula. For example, assuming that the target voting duration is 48 hours and the average block generation time is 10 seconds, the first calculation duration is 172790 seconds. Furthermore, the first number of calculations Tmax can be determined according to the preset VDF algorithm and the first calculation duration. Specifically, the VDF formula of the preset VDF algorithm can be obtained, and the duration of calculating the VDF formula once can be estimated according to the average calculation performance parameter to obtain the single calculation duration. The first number of calculations Tmax = first calculation duration / single calculation duration.

[0070] In this way, by determining the first number of calculations, a reasonable voting calculation difficulty can be set to prevent malicious participants from manipulating voting results through fast calculations, making it impossible for attackers to forge a large number of votes by simply increasing the calculation speed, thereby ensuring the fairness of the voting process.

[0071] S104. Determine nodes in the initial blockchain that have voting intentions, and obtain m nodes, where m is a natural number.

[0072] In an embodiment of the present application, nodes in the initial blockchain that have voting intentions are determined, and m nodes are obtained. Specifically, since the target edit request txeditreq has been publicly uploaded to the chain, all nodes in the initial blockchain can view it. Nodes that want to participate in the vote can send a preset message to the voting contract to indicate their voting intentions, thereby obtaining m nodes.

[0073] It needs to be explained that these m nodes all have VDF computing capabilities.

[0074] S105. Obtain the voting transaction of each of the m nodes through the voting contract to obtain m voting transactions; each voting transaction includes a voting result and a VDF calculation result; the VDF calculation result is the result obtained by the nodes among the m nodes performing VDF calculation based on the first parameter set.

[0075] In an embodiment of the present application, each of the m nodes can vote on its own to generate m voting results, and perform VDF calculation according to the first parameter set to obtain m VDF calculation results. Then, the generated m voting results and the corresponding VDF calculation results in the m VDF calculation results are packaged to obtain m voting transactions. Finally, the m nodes can send these m voting transactions to the voting contract.

[0076] Optionally, in step S105, the first parameter set includes: a VDF formula, a VDF proof algorithm, and VDF calculation parameters; and obtaining the voting transaction of each of the m nodes through the voting contract to obtain m voting transactions includes:

[0077] C1. Obtain a first voting registration transaction issued by a first node, and publicly upload the first voting registration transaction to the blockchain; the first voting registration transaction includes a detailed edit request of the target edit request txeditreq; the first node is any one of the m nodes;

[0078] C2. Obtain the block height corresponding to the first voting registration transaction to obtain the first voting registration block height;

[0079] C3. Obtain the first node ID of the first node;

[0080] C4. Determine, through the voting contract and based on the first node ID, whether the first node has a valid vote.

[0081] C5. If so, mark the first voting registration transaction as an invalid transaction;

[0082] C6. If it does not exist, concatenate the first voting registration block height and the first node ID through the first node to obtain a first input parameter x; input the first input parameter x and the VDF calculation parameters into the VDF formula, calculate the target VDF calculation number Teditreq, and obtain a first output y and a first proof π;

[0083] C7. Generate a first voting result through the first node, generate a first voting transaction corresponding to the first node based on the first voting result and the first VDF calculation result, and send the first voting transaction to the voting contract. The first voting result includes one of the following: approval or disapproval. The first VDF calculation result includes: first input parameter x, first output y, first proof π, and target VDF calculation times Teditreq.

[0084] C8. Verify the first voting transaction using the voting contract to obtain a first verification result. The first verification result includes one of the following: verification success or verification failure.

[0085] C9. When the first verification result includes verification success, determining that the first voting transaction is the transaction corresponding to the first node among the m voting transactions;

[0086] C10. When the first verification result includes the verification failure, mark the first voting transaction as an invalid transaction.

[0087] In the embodiment of the present application, the VDF calculation parameters can be preset or defaulted in advance.

[0088] In a specific embodiment, when the first node wants to participate in voting editing, the first node will generate a first voting registration transaction, send the first voting registration transaction to the voting transaction, and make the first voting registration transaction public on the chain; then, the block height corresponding to the first voting registration transaction can be obtained to obtain the first voting registration block height. Specifically, the first voting registration transaction can be monitored through the target blockchain browser, and the block height information to which it belongs can be found in the transaction details page, thereby obtaining the first voting registration block height. Of course, the first voting registration block height can also be queried through other feasible methods, for example, using a blockchain development toolkit to obtain, a command line tool query, etc.; then, the node information of the first node can be obtained through the target blockchain browser, and the first node ID can be obtained from the node information. Then, the voting contract can be used to determine whether the first node has a valid vote based on the first node ID. Specifically, the voting contract will list and store a voting record table of all valid votes on the chain. The format of the voting record table is shown in Table 1. Table 1 is as follows:

[0089] Table 1

[0090]

[0091] The voting contract can query whether the first node ID exists in the voting record table. If it exists, it means that the first node has a valid vote. If it does not exist, it means that the first node does not have a valid vote.

[0092] It should be explained that a voting result v of 1 indicates that the node agrees with the edit operation requested by the vote, and a voting result v of 0 indicates that the node opposes the edit operation requested by the vote.

[0093] If it exists, the first voting registration transaction is marked as an invalid transaction. Specifically, in the voting contract, a first state variable can be assigned to the first voting registration transaction, and the first state variable can be set to an invalid state, that is, the first voting registration transaction is marked as an invalid transaction.

[0094] If it does not exist, the first state variable can be set to the valid state. Then, the first voting registration block height and the first node ID are spliced ​​together through the first node to obtain the first input parameter x. For example, assuming that the first voting registration block height is 200 and the first node ID is 3J98t1WpEZ73CNm, the first input parameter x obtained by splicing the two is 2003J98t1WpEZ73CNm. Then, the first input parameter x and the VDF calculation parameters can be input into the VDF formula to calculate the target VDF calculation times Teditreq (that is, T in the repeated square method) to obtain the first output y and the first proof π, as follows:

[0095] (y,π)=Eval(ek,x);

[0096] Where ek is a VDF calculation parameter, and Eval() is a VDF formula. Next, a first voting result can be generated by the first node. The first voting result can be 0 or 1, where 0 represents opposition and 1 represents approval. Next, a first voting transaction corresponding to the first node can be generated based on the first voting result and the first VDF calculation result. Specifically, the first voting result and the first VDF calculation result can be directly packaged and collated to obtain a first voting transaction. The first voting transaction can then be sent to the voting contract. The first voting transaction is verified by the voting contract to obtain a first verification result. When the first verification result includes verification success, the first voting transaction is determined to be the transaction corresponding to the first node among the m voting transactions.

[0097] When the first verification result includes verification failure, the first voting transaction is marked as an invalid transaction.

[0098] It should be explained that when a node already has a valid vote and wants to vote again, the node can send a re-vote request to the voting contract. When the re-vote request is received by the voting contract, the previous vote will be marked as invalid to prevent a single node from having multiple valid votes.

[0099] In this way, by making the first voting registration transaction issued by the first node public on the chain, it is ensured that all participants can obtain the detailed editing request information of the target editing request, and the voting process leaves an unalterable record on the blockchain. Any node can view and verify this information, which increases the transparency of the voting system. In addition, by using the voting contract to determine whether the node has a valid vote based on the first node ID, it can effectively prevent the node from voting repeatedly and improve the reliability of voting.

[0100] Optionally, before the step of inputting the first input parameter x and the VDF calculation parameter into the VDF formula, calculating the target VDF calculation number Teditreq, and obtaining the first output y and the first proof π, the method further includes:

[0101] D1. Obtain the target VDF calculation times Teditreq at the current moment, and record it as the current VDF calculation times;

[0102] D2. Obtain the number of valid votes for the target edit request txeditreq in the voting contract at the current moment to obtain the target number;

[0103] D3. Determine a target adjustment coefficient based on the target number, the preset difficulty adjustment factor, and the preset number;

[0104] D4. Adjust the current VDF calculation times according to the target adjustment coefficient to obtain a reference VDF calculation time; the reference VDF calculation time is greater than the current VDF calculation time and less than or equal to the first calculation time Tmax;

[0105] D5. Update the value of the target VDF calculation times Teditreq to the value of the reference VDF calculation times to obtain the updated target VDF calculation times Teditreq.

[0106] In an embodiment of the present application, the preset difficulty adjustment factor can be preset in advance or defaulted, and the preset difficulty adjustment factor is used to adjust the difficulty of VDF calculation; the preset number can be preset in advance or defaulted.

[0107] In a specific embodiment, the target VDF calculation number Teditreq stored in the voting contract at the current moment can be obtained and recorded as the current VDF calculation number; then, the number of valid votes for the target edit request txeditreq in the voting contract at the current moment can be obtained to obtain the target number. Specifically, the number of votes in the voting record table can be checked, which is the target number; then, the target adjustment coefficient can be determined based on the target number, the preset difficulty adjustment factor, and the preset number, as follows:

[0108] Target adjustment coefficient = preset difficulty adjustment factor * target number / preset number;

[0109] The target adjustment coefficient can be obtained according to the above formula. The target adjustment coefficient is an integer greater than 1. Then, the current VDF calculation times can be adjusted according to the target adjustment coefficient, as follows:

[0110]

[0111] Among them, t1 is the current VDF calculation number, R is the target adjustment coefficient, Tmax is the first calculation number, and t3 is the reference VDF calculation number; according to the above formula, the reference VDF calculation number can be obtained; then, the value of the target VDF calculation number Teditreq can be updated to the value of the reference VDF calculation number to obtain the updated target VDF calculation number Teditreq.

[0112] In this way, by obtaining the number of VDF calculations and the number of valid votes at the current moment, the number of VDF calculations can be dynamically adjusted according to the real-time progress of the voting, forming an adaptive mechanism. This allows the system to flexibly change the calculation requirements according to the actual scale of voting participation. For example, when the number of participants is small at the beginning of the voting, the calculation difficulty can be appropriately reduced. As the number of voters increases, the calculation difficulty can be increased accordingly to adapt to the voting situation at different stages.

[0113] Optionally, verifying the first voting transaction to obtain a first verification result includes:

[0114] E1. Reversely infer the block height corresponding to the first voting registration transaction based on the first voting transaction to obtain a second voting registration block height;

[0115] E2. Determine whether the second voting registration block height is consistent with the first voting registration block height;

[0116] E3. If they are inconsistent, mark the first voting transaction as an invalid transaction;

[0117] E4. If they are consistent, verify the first VDF calculation result using the VDF proof algorithm to obtain the first verification result.

[0118] In the embodiment of the present application, the block height corresponding to the first voting registration transaction can be inferred from the first voting transaction to obtain the second voting registration block height. Specifically, the first input parameter x in the first voting transaction can be obtained and split to obtain the second voting registration block height. For example, assuming that the first input parameter x is 2003J98t1WpEZ73CNm, the second voting registration block height is 200. Then, the second voting registration block height can be compared with the first voting registration block height to see if they are consistent. If they are inconsistent, the first voting transaction is marked as an invalid transaction.

[0119] If they are consistent, the first VDF calculation result is verified by the VDF proof algorithm to obtain a first verification result. Specifically, the VDF proof algorithm can be Boneh interactive verification. The VDF proof algorithm is executed on the first proof π in the first VDF calculation result to verify whether it is obtained based on the first input parameter x, the first output y, and the target VDF calculation times Teditreq. If so, the first verification result is a successful verification. Otherwise, the first verification result is a failed verification.

[0120] In this way, the VDF proof algorithm verifies the first VDF calculation result only when the height of the second voting registration block is consistent with the height of the first voting registration block. This can eliminate the interference of abnormal voting transactions that may be caused by data inconsistency on the verification process, ensuring that the voting transactions used for VDF verification are generated based on original, untampered data, thereby improving the reliability of VDF verification.

[0121] S106: Determine whether the target edit request txeditreq is passed by voting according to the m voting transactions.

[0122] In an embodiment of the present application, m voting results corresponding to m voting transactions can be obtained, and the number of votes in favor of the target editing request txeditreq in the m voting results can be determined to obtain the number of approval votes. If the number of approval votes is greater than half of m, it is determined that the target editing request txeditreq is passed. If the number of approval votes is not greater than half of m, it is determined that the target editing request txeditreq is not passed.

[0123] S107. When the target edit request txeditreq is voted through, the initial blockchain is edited based on a preset blockchain editing algorithm and the target edit request txeditreq to obtain a target blockchain.

[0124] In the embodiment of the present application, the preset blockchain editing algorithm can be preset or defaulted in advance.

[0125] In a specific embodiment, when the target edit request txeditreq is voted through, the editing operation corresponding to the target edit request txeditreq is performed on the initial blockchain according to the preset blockchain editing algorithm to obtain the target blockchain.

[0126] When the target edit request txeditreq fails to pass the vote, the target edit request txeditreq is not executed.

[0127] Optionally, in step S107, the preset blockchain editing algorithm includes a preset Chameleon Hash algorithm; and editing the initial blockchain based on the preset blockchain editing algorithm and the target edit request txeditreq to obtain the target blockchain includes:

[0128] F1. Obtain the public key hk and the trapdoor private key td corresponding to the preset Chameleon Hash algorithm, and make the public key hk and the trapdoor private key td public on the blockchain;

[0129] F2. Create a new transaction block B' for the old transaction block B based on the public key hk and the trapdoor private key td; replace the old transaction tx in the new transaction block B' with the new transaction tx', and other data in the new transaction block B' is the same as that in the old transaction block B;

[0130] F3. Obtain the first transaction tree root hash of the old transaction block B;

[0131] F4. Generate a first auxiliary random number corresponding to the new transaction tx' using the preset chameleon hash algorithm; the first auxiliary random number is used to make the second transaction tree root hash corresponding to the new transaction tx' equal to the first transaction tree root hash;

[0132] F5. Calculate the hash value of the new transaction block B' using a preset hash algorithm to obtain a new block hash value. Calculate a second auxiliary random number using a preset ChForge algorithm, and determine whether the old Chameleon hash value of the old transaction block B remains unchanged based on the second auxiliary random number.

[0133] F6. When the old chameleon hash value remains unchanged, insert the new transaction block B' into the initial blockchain according to the new block hash value to obtain the target blockchain.

[0134] In the embodiment of the present application, the preset Chameleon hash algorithm, the preset hash algorithm, and the preset ChForge algorithm can be preset in advance or defaulted; each newly generated block header in the blockchain includes the fields in Table 2, which are as follows:

[0135] Table 2

[0136]

[0137] Among them, PrevBlock, NextBlock: newly added fields, pointing to the block height of the previous block / next block after editing.

[0138] RValue: A new field stored in this block, used to calculate the PrevChHash of the previous block. Before editing, this value is 0, and no PrevChHash calculation is required. After editing, it is used for PrevChHash calculation.

[0139] PrevChHash: A new field pointing to the Chameleon Hash of the previous block, which is calculated as ChHash(hk, PrevHash, RValue). Due to the characteristics of Chameleon Hash, the edited PrevChHash should not change.

[0140] PrevHash, TxRoot: Legacy fields, representing the SHA hash value of the previous block (usually obtained using SHA3 / SHA256) and the transaction tree root of this block, respectively.

[0141] In a specific embodiment, the public key hk and trapdoor private key td corresponding to the preset chameleon hash algorithm can be obtained. Since the preset chameleon hash algorithm is a prior art, it will not be described in detail here. Then, the public key hk and trapdoor private key td can be made public on the chain; then, a new transaction block B' can be created for the old transaction block B based on the public key hk and trapdoor private key td, and the old transaction tx in the new transaction block B' is replaced by the new transaction tx'. The other data in the new transaction block B' is the same as the old transaction block B. Specifically, all the data of the old transaction block B can be obtained from the blockchain ledger or storage medium of the initial blockchain, and the first storage position of the old transaction tx in the new transaction block B' is determined, the old transaction tx is deleted from it, and the new transaction tx' is written to the first storage position, thereby constructing a new transaction block B'.

[0142] Next, the first transaction tree root hash of the old transaction block B can be obtained. Specifically, all transaction data of the old transaction block B can be obtained through the target blockchain browser, and a Merkle tree can be constructed based on the obtained transaction data. The Merkle tree can be a binary tree, and the hash value of the root node of the Merkle tree is the first transaction tree root hash; then, the first auxiliary random number corresponding to the new transaction tx' can be generated through the preset chameleon hash algorithm. This is a feature of the preset chameleon hash algorithm itself. Specifically, for the original transaction tx and its corresponding auxiliary random number, the two can generate a transaction tree root hash; when there is a new transaction tx', it will be substituted into the preset chameleon hash algorithm, and a new auxiliary random number (i.e., the first auxiliary random number) can be found in a relatively short time, so that the transaction tree root hash remains unchanged.

[0143] Furthermore, a preset hash algorithm can be used to calculate the hash value of the new transaction block B' to obtain a new block hash value. Specifically, the preset hash algorithm can be SHA256. Various data of the new transaction block B' (for example, block data, transaction data, etc.) are obtained, and these data are arranged in a preset order and input into the SHA256 function for calculation to obtain a new block hash value. In addition, a second auxiliary random number is calculated by the preset ChForge algorithm. Since the ChForge algorithm is a conventional technology, it is not described here. The second auxiliary random number and the new transaction tx' are brought into the preset chameleon hash algorithm to calculate the new chameleon hash value, obtain the old chameleon hash value of the old transaction block B, and compare the new chameleon hash value with the old chameleon hash value to see if they are equal. If they are equal, it is determined that the old chameleon hash value of the old transaction block B is unchanged, and no error occurs during the editing process.

[0144] If they are not equal, it is determined that the old chameleon hash value of the old transaction block B has changed, an error has occurred during the editing process, and the editing can be performed again.

[0145] It should be explained that if the first auxiliary random number obtained is correct, the first auxiliary random number and the second auxiliary random number can be equal; the ChForge algorithm is an algorithm for generating specific parameters (RValue in this application) to ensure that the ChHash value of the old block remains unchanged after certain modifications are made to the block (such as updating transactions, etc.).

[0146] Then, when the old chameleon hash value remains unchanged, it means that there is no error in the editing process, and you can proceed to the next step, inserting the new transaction block B' into the initial blockchain according to the new block hash value to obtain the target blockchain.

[0147] By making the public key and trapdoor private key td corresponding to the preset Chameleon hash algorithm publicly available on-chain, all nodes in the blockchain network can access this critical information. This transparency facilitates mutual oversight between nodes, preventing malicious use of keys or tampering by individual nodes, as any abnormal key usage can be verified by other nodes using the public key.

[0148] Optionally, step F6, inserting the new transaction block B' into the initial blockchain according to the new block hash value to obtain the target blockchain, includes:

[0149] G1. In the initial blockchain, determine the block before the old transaction block B, denoted as the target previous block Bpre, and determine the block after the old transaction block B, denoted as the target next block Bnext;

[0150] G2. Determine the target index corresponding to the new transaction block B'; the target index is used to point to the new transaction block B';

[0151] G3. Modify the backward index of the target previous block Bpre to the target index, and modify the forward index of the target next block Bnext to the target index;

[0152] G4. Modify the hash value of the previous block stored in the target block header of the target next block Bnext to the new block hash value, and replace the auxiliary random number stored in the target block header with the second auxiliary random number;

[0153] G5. The block modification transaction is publicly uploaded to the target blockchain through the target node to obtain the target blockchain; the block modification transaction includes: the target edit request txeditreq, the block height corresponding to the target edit request txeditreq, the target VDF calculation times Teditreq stored in the voting initiation contract at the end of the vote, the m voting results, the new transaction tx', and the block height of the new transaction block B'.

[0154] In an embodiment of the present application, the previous block of the old transaction block B in the initial blockchain can be obtained, which is recorded as the target previous block Bpre, and the next block of the old transaction block B can be recorded as the target next block Bnext. Specifically, the block header of the old transaction block B can be queried from the preset blockchain database to obtain the block fields PrevBlock and NextBlock of the old transaction block B. According to PrevBlock and NextBlock, the target previous block Bpre and the target next block Bnext can be queried; then, the target index corresponding to the new transaction block B' can be determined. Specifically, the target index can be generated according to the new block hash value. For example, a mapping relationship between a preset block hash value and an index can be pre-stored, and the target index corresponding to the new block hash value can be determined based on the mapping relationship.

[0155] Then, the backward index of the target previous block Bpre can be modified to the target index, and the forward index of the target post block Bnext can be modified to the target index; further, the hash value of the previous block stored in the target block header of the target post block Bnext is modified to the new block hash value, and the auxiliary random number stored in the target block header is replaced with the second auxiliary random number; finally, the block modification transaction can be made public on the chain through the target node to obtain the target blockchain.

[0156] For an example, see Figure 2 , Figure 2 This is a flowchart of a blockchain editing process provided by an embodiment of the present application, such as Figure 2 As shown, before editing, the block height of the old transaction block B is 300, the previous block of the old transaction block B is the target previous block Bpre, and the next block is the target next block Bnext. After editing, the backward index of the target previous block Bpre is modified to the target index, that is, the next block of the target previous block Bpre is modified to the new transaction block B', and the block height of the new transaction block B' is 1700. Then, the forward index of the target next block Bnext is modified to the target index, that is, the previous block of the target next block Bnext is modified to the new transaction block B'.

[0157] In this way, after the blockchain is edited, if a node traverses the target blockchain, when the node traverses the block containing the block modification transaction, it will know to bypass the newly generated "B'" block related to it and continue to traverse other blocks. Figure 2 When a node reads the block marked "Bnext" in the header, the operation changes. The node will read the "B'" block instead. After reading the "B'" block, it will read the "Bpre" block based on the information pointed to in the "B'" block header. This method can achieve a complete and correct traversal of the edited blockchain, ensuring that the blockchain can still be accessed and processed by nodes according to the specified logic and order after editing.

[0158] It can be seen that the VDF-based on-chain voting method provided in the embodiment of the present application obtains the first parameter set of the preset VDF algorithm. When the blockchain needs to edit the vote, each node in the blockchain performs VDF calculation and votes according to the first parameter set to obtain the VDF calculation result and the voting result. The voting result and the VDF calculation result are interrelated and verifiable. When verifying the voting transaction (that is, the VDF calculation result and the voting result), not only can it be checked whether the voting result itself complies with the rules, but the authenticity of the voting transaction can also be judged by verifying the VDF calculation result. In this way, by performing multiple verifications on the voting transaction, malicious nodes can be effectively prevented from submitting false votes, and without relying on a reliable third party, the security of the blockchain voting process in an unregulated scenario can be ensured.

[0159] See also Figure 3 , Figure 3 This is a functional unit structure diagram of a VDF-based on-chain voting device 300 provided in an embodiment of the present application. The VDF-based on-chain voting device 300 is applied to an initial blockchain. Each node in the initial blockchain includes a voting initiation contract and a voting contract. The VDF-based on-chain voting device 300 includes: an acquisition unit 301, a voting unit 302, and an editing unit 303, wherein:

[0160] The acquisition unit 301 is configured to acquire a first parameter set corresponding to a preset VDF algorithm; acquire a target edit request txeditreq initiated by a target node; the target node is any node in the initial blockchain;

[0161] The voting unit 302 is configured to write the target edit request txeditreq into the voting initiation contract through the target node, and determine the target VDF calculation times Teditreq corresponding to the target edit request txeditreq through the voting initiation contract; determine the nodes in the initial blockchain that have voting intentions, and obtain m nodes; m is a natural number; obtain the voting transaction of each of the m nodes through the voting contract, and obtain m voting transactions; each voting transaction includes a voting result and a VDF calculation result; the VDF calculation result is the result obtained by the nodes in the m nodes performing VDF calculation based on the first parameter set; determine whether the target edit request txeditreq is voted through based on the m voting transactions;

[0162] The editing unit 303 is configured to edit the initial blockchain based on a preset blockchain editing algorithm and the target editing request txeditreq to obtain a target blockchain when the target editing request txeditreq is voted through.

[0163] Optionally, the target edit request txeditreq includes: the old transaction tx, the new transaction tx', the old transaction block B where the old transaction tx is located, and the block height BH to be edited of the old transaction block B. B In determining the target VDF calculation times Teditreq corresponding to the target edit request txeditreq by initiating the contract through voting, the voting unit 302 is specifically used to:

[0164] Obtaining the average block frequency t of the initial blockchain;

[0165] Obtaining average computing performance parameters of the hardware devices corresponding to the initial blockchain;

[0166] Determine the basic calculation times Tbase according to the block generation frequency t and the average calculation performance parameter;

[0167] Determine the current block height of the target node

[0168] Estimate the first number of calculations Tmax required from the target edit request txeditreq being written into the voting initiation contract to the end of the voting;

[0169] According to the basic calculation times Tbase, the current block height The first calculation times Tmax, the height of the block to be edited BH B The target VDF calculation times Teditreq is determined by the preset times calculation formula.

[0170] Optionally, in terms of estimating a first number of calculations Tmax required from writing the target edit request txeditreq into the voting initiation contract to the end of voting, the voting unit 302 is specifically configured to:

[0171] Determine the target voting duration corresponding to the target edit request txeditreq;

[0172] Determine a first calculation duration according to the target voting duration and the average block generation frequency t;

[0173] The first calculation times Tmax are determined according to the preset VDF algorithm and the first calculation duration.

[0174] Optionally, the first parameter set includes: a VDF formula, a VDF proof algorithm, and VDF calculation parameters; in obtaining the voting transaction of each of the m nodes through the voting contract to obtain m voting transactions, the voting unit 302 is specifically configured to:

[0175] Obtain a first voting registration transaction issued by a first node, and publicly upload the first voting registration transaction to the blockchain; the first voting registration transaction includes a detailed edit request of the target edit request txeditreq; the first node is any one of the m nodes;

[0176] Obtaining the block height corresponding to the first voting registration transaction to obtain the first voting registration block height;

[0177] Obtaining a first node ID of the first node;

[0178] Determining, by the voting contract and based on the first node ID, whether the first node has a valid vote;

[0179] If so, marking the first voting registration transaction as an invalid transaction;

[0180] If it does not exist, concatenate the first voting registration block height and the first node ID through the first node to obtain a first input parameter x; input the first input parameter x and the VDF calculation parameters into the VDF formula, calculate the target VDF calculation times Teditreq, and obtain a first output y and a first proof π;

[0181] Generate a first voting result through the first node, generate a first voting transaction corresponding to the first node based on the first voting result and the first VDF calculation result, and send the first voting transaction to the voting contract; the first voting result includes one of the following: approval or disapproval; the first VDF calculation result includes: first input parameter x, first output y, first proof π, and target VDF calculation times Teditreq;

[0182] Verify the first voting transaction through the voting contract to obtain a first verification result; the first verification result includes one of the following: verification success or verification failure;

[0183] When the first verification result includes verification success, determining that the first voting transaction is a transaction corresponding to the first node among the m voting transactions;

[0184] When the first verification result includes the verification failure, the first voting transaction is marked as an invalid transaction.

[0185] Optionally, before the step of inputting the first input parameter x and the VDF calculation parameter into the VDF formula, calculating the target VDF calculation times Teditreq, and obtaining the first output y and the first proof π, the VDF-based on-chain voting device 300 is further specifically configured to:

[0186] Get the target VDF calculation times Teditreq at the current moment, and record it as the current VDF calculation times;

[0187] Obtain the number of valid votes for the target edit request txeditreq in the voting contract at the current moment to obtain the target number;

[0188] Determining a target adjustment coefficient based on the target number, a preset difficulty adjustment factor, and a preset number;

[0189] Adjusting the current VDF calculation times according to the target adjustment coefficient to obtain a reference VDF calculation times; the reference VDF calculation times is greater than the current VDF calculation times and less than or equal to the first calculation times Tmax;

[0190] The value of the target VDF calculation times Teditreq is updated to the value of the reference VDF calculation times to obtain the updated target VDF calculation times Teditreq.

[0191] Optionally, the first voting transaction is verified to obtain a first verification result, and the voting unit 302 is specifically configured to:

[0192] Reversely inferring the block height corresponding to the first voting registration transaction based on the first voting transaction to obtain a second voting registration block height;

[0193] determining whether the second voting registration block height is consistent with the first voting registration block height;

[0194] If they are inconsistent, the first voting transaction is marked as an invalid transaction;

[0195] If they are consistent, the first VDF calculation result is verified using the VDF proof algorithm to obtain the first verification result.

[0196] Optionally, the preset blockchain editing algorithm includes a preset chameleon hash algorithm; in editing the initial blockchain based on the preset blockchain editing algorithm and the target edit request txeditreq to obtain the target blockchain, the editing unit 303 is specifically configured to:

[0197] Obtain the public key hk and the trapdoor private key td corresponding to the preset chameleon hash algorithm, and make the public key hk and the trapdoor private key td public on the blockchain;

[0198] A new transaction block B' is created for the old transaction block B based on the public key hk and the trapdoor private key td; the old transaction tx is replaced by the new transaction tx' in the new transaction block B', and other data in the new transaction block B' is the same as that in the old transaction block B;

[0199] Obtain the first transaction tree root hash of the old transaction block B;

[0200] Generate a first auxiliary random number corresponding to the new transaction tx' using the preset chameleon hash algorithm; the first auxiliary random number is used to make the second transaction tree root hash corresponding to the new transaction tx' equal to the first transaction tree root hash;

[0201] Calculate the hash value of the new transaction block B' using a preset hash algorithm to obtain a new block hash value, and calculate a second auxiliary random number using a preset ChForge algorithm, and determine whether the old chameleon hash value of the old transaction block B is unchanged based on the second auxiliary random number;

[0202] When the old chameleon hash value remains unchanged, the new transaction block B' is inserted into the initial blockchain according to the new block hash value to obtain the target blockchain.

[0203] Optionally, in inserting the new transaction block B' into the initial blockchain according to the new block hash value to obtain the target blockchain, the editing unit 303 is specifically configured to:

[0204] In the initial blockchain, the previous block of the old transaction block B is determined, recorded as the target previous block Bpre, and the next block of the old transaction block B is determined, recorded as the target next block Bnext;

[0205] Determine a target index corresponding to the new transaction block B'; the target index is used to point to the new transaction block B';

[0206] Modify the backward index of the target previous block Bpre to the target index, and modify the forward index of the target next block Bnext to the target index;

[0207] Modify the hash value of the previous block stored in the target block header of the target next block Bnext to the new block hash value, and replace the auxiliary random number stored in the target block header with the second auxiliary random number;

[0208] The block modification transaction is made public on the chain through the target node to obtain the target blockchain; the block modification transaction includes: the target edit request txeditreq, the block height corresponding to the target edit request txeditreq, the target VDF calculation times Teditreq stored in the voting initiation contract at the end of the voting, the m voting results, the new transaction tx', and the block height of the new transaction block B'.

[0209] In a specific implementation, the VDF-based on-chain voting device 300 described in the embodiment of the present invention can also execute other implementation methods described in the VDF-based on-chain voting method provided in the above embodiment of the present invention, which will not be repeated here.

[0210] See also Figure 4 , Figure 4 This is a structural diagram of an electronic device provided in an embodiment of the present application. The electronic device includes a processor, a memory, a communication interface, and one or more programs. The processor, memory, and communication interface are interconnected via a bus. The one or more programs are stored in the memory and are configured to be executed by the processor. The one or more programs include instructions for executing other implementations described in the VDF-based on-chain voting method provided in the above embodiment of the present invention, which will not be repeated here.

[0211] An embodiment of the present application also provides a computer storage medium, wherein the computer storage medium stores a computer program for electronic data exchange, and the computer program enables a computer to execute part or all of the steps of any method described in the above method embodiments, and the above computer includes an electronic device.

[0212] The present application also provides a computer program product comprising a non-transitory computer-readable storage medium storing a computer program, wherein the computer program is operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may comprise an electronic device.

[0213] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0214] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0215] In the several embodiments provided in this application, it should be understood that the disclosed devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the above-mentioned units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components 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 through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

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

[0217] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0218] If the above-mentioned 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 memory. Based on this understanding, the technical solution of the present application, 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, which is stored in a memory and includes a number of instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the above-mentioned methods of each embodiment of the present application. The aforementioned memory includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0219] The above is a detailed introduction to the embodiments of the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. At the same time, for those skilled in the art, according to the idea of ​​the present application, there may be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A VDF-based on-chain voting method, characterized in that: Applied to an initial blockchain, each node in the initial blockchain includes a voting initiation contract and a voting contract. The method includes: Obtain a first parameter set corresponding to a preset VDF algorithm; Obtain a target edit request txeditreq initiated by a target node; the target node is any node in the initial blockchain; The target edit request txeditreq is written into the voting initiation contract through the target node, and the target VDF calculation times Teditreq corresponding to the target edit request txeditreq is determined through the voting initiation contract; Determine nodes in the initial blockchain that have voting intentions, and obtain m nodes; m is a natural number; Obtaining, through the voting contract, voting transactions of each of the m nodes to obtain m voting transactions; each voting transaction includes a voting result and a VDF calculation result; the VDF calculation result is a result obtained by performing VDF calculations on the m nodes based on the first parameter set; Determine whether the target edit request txeditreq is passed according to the m voting transactions; When the target edit request txeditreq is voted through, the initial blockchain is edited based on the preset blockchain editing algorithm and the target edit request txeditreq to obtain the target blockchain.

2. The method according to claim 1, wherein The target edit request txeditreq includes: the old transaction tx, the new transaction tx', the old transaction block B where the old transaction tx is located, and the block height BH to be edited of the old transaction block B. B The process of initiating the contract through voting to determine the target VDF calculation times Teditreq corresponding to the target edit request txeditreq includes: Obtaining the average block frequency t of the initial blockchain; Obtaining average computing performance parameters of the hardware devices corresponding to the initial blockchain; Determine the basic calculation times Tbase according to the average block frequency t and the average calculation performance parameter; Determine the current block height BH of the target node ¬MAX ; Estimate the first number of calculations Tmax required from the target edit request txeditreq being written into the voting initiation contract to the end of the voting; According to the basic calculation times Tbase, the current block height BH ¬MAX , the first calculation times Tmax, the height of the block to be edited BH B The target VDF calculation times Teditreq is determined by the preset times calculation formula.

3. The method according to claim 2, wherein The estimated first number of calculations Tmax required from writing the target edit request txeditreq into the voting initiation contract to the end of the voting includes: Determine the target voting duration corresponding to the target edit request txeditreq; Determine a first calculation duration according to the target voting duration and the average block generation frequency t; The first calculation times Tmax are determined according to the preset VDF algorithm and the first calculation duration.

4. The method according to claim 2 or 3, wherein: The first parameter set includes: a VDF formula, a VDF proof algorithm, and VDF calculation parameters; the voting transaction of each of the m nodes is obtained through the voting contract to obtain m voting transactions, including: Obtain a first voting registration transaction issued by a first node, and publicly upload the first voting registration transaction to the blockchain; the first voting registration transaction includes a detailed edit request of the target edit request txeditreq; the first node is any one of the m nodes; Obtaining the block height corresponding to the first voting registration transaction to obtain the first voting registration block height; Obtaining a first node ID of the first node; Determining, by the voting contract and based on the first node ID, whether the first node has a valid vote; If so, marking the first voting registration transaction as an invalid transaction; If it does not exist, concatenate the first voting registration block height and the first node ID through the first node to obtain a first input parameter x; input the first input parameter x and the VDF calculation parameters into the VDF formula, calculate the target VDF calculation times Teditreq, and obtain a first output y and a first proof π; Generate a first voting result through the first node, generate a first voting transaction corresponding to the first node based on the first voting result and the first VDF calculation result, and send the first voting transaction to the voting contract; the first voting result includes one of the following: approval or disapproval; the first VDF calculation result includes: first input parameter x, first output y, first proof π, and target VDF calculation times Teditreq; Verify the first voting transaction through the voting contract to obtain a first verification result; the first verification result includes one of the following: verification success or verification failure; When the first verification result includes verification success, determining that the first voting transaction is a transaction corresponding to the first node among the m voting transactions; When the first verification result includes the verification failure, the first voting transaction is marked as an invalid transaction.

5. The method according to claim 4, wherein Before the step of inputting the first input parameter x and the VDF calculation parameter into the VDF formula, calculating the target VDF calculation number Teditreq, and obtaining the first output y and the first proof π, the method further includes: Get the target VDF calculation times Teditreq at the current moment, and record it as the current VDF calculation times; Obtain the number of valid votes for the target edit request txeditreq in the voting contract at the current moment to obtain the target number; Determining a target adjustment coefficient based on the target number, a preset difficulty adjustment factor, and a preset number; Adjusting the current VDF calculation times according to the target adjustment coefficient to obtain a reference VDF calculation times; the reference VDF calculation times is greater than the current VDF calculation times and less than or equal to the first calculation times Tmax; The value of the target VDF calculation times Teditreq is updated to the value of the reference VDF calculation times to obtain the updated target VDF calculation times Teditreq.

6. The method according to claim 5, wherein The verifying the first voting transaction to obtain a first verification result includes: Reversely inferring the block height corresponding to the first voting registration transaction based on the first voting transaction to obtain a second voting registration block height; determining whether the second voting registration block height is consistent with the first voting registration block height; If they are inconsistent, the first voting transaction is marked as an invalid transaction; If they are consistent, the first VDF calculation result is verified using the VDF proof algorithm to obtain the first verification result.

7. The method according to claim 2 or 3, wherein: The preset blockchain editing algorithm includes a preset chameleon hash algorithm; and editing the initial blockchain based on the preset blockchain editing algorithm and the target editing request txeditreq to obtain a target blockchain includes: Obtain the public key hk and the trapdoor private key td corresponding to the preset chameleon hash algorithm, and make the public key hk and the trapdoor private key td public on the blockchain; A new transaction block B' is created for the old transaction block B based on the public key hk and the trapdoor private key td; the old transaction tx is replaced by the new transaction tx' in the new transaction block B', and other data in the new transaction block B' is the same as that in the old transaction block B; Obtain the first transaction tree root hash of the old transaction block B; Generate a first auxiliary random number corresponding to the new transaction tx' using the preset chameleon hash algorithm; the first auxiliary random number is used to make the second transaction tree root hash corresponding to the new transaction tx' equal to the first transaction tree root hash; Calculate the hash value of the new transaction block B' using a preset hash algorithm to obtain a new block hash value, and calculate a second auxiliary random number using a preset ChForge algorithm, and determine whether the old chameleon hash value of the old transaction block B is unchanged based on the second auxiliary random number; When the old chameleon hash value remains unchanged, the new transaction block B' is inserted into the initial blockchain according to the new block hash value to obtain the target blockchain.

8. The method according to claim 7, wherein Inserting the new transaction block B' into the initial blockchain according to the new block hash value to obtain the target blockchain includes: In the initial blockchain, the previous block of the old transaction block B is determined, recorded as the target previous block Bpre, and the next block of the old transaction block B is determined, recorded as the target next block Bnext; Determine a target index corresponding to the new transaction block B'; the target index is used to point to the new transaction block B'; Modify the backward index of the target previous block Bpre to the target index, and modify the forward index of the target next block Bnext to the target index; Modify the hash value of the previous block stored in the target block header of the target next block Bnext to the new block hash value, and replace the auxiliary random number stored in the target block header with the second auxiliary random number; The block modification transaction is made public on the chain through the target node to obtain the target blockchain; the block modification transaction includes: the target edit request txeditreq, the block height corresponding to the target edit request txeditreq, the target VDF calculation times Teditreq stored in the voting initiation contract at the end of the voting, the m voting results corresponding to the m voting transactions, the new transaction tx', and the block height of the new transaction block B'.

9. A VDF-based on-chain voting device, characterized in that: Applied to the initial blockchain, each node in the initial blockchain includes a voting initiation contract and a voting contract, and the device includes: an acquisition unit, a voting unit, and an editing unit, wherein: The acquisition unit is configured to acquire a first parameter set corresponding to a preset VDF algorithm; acquire a target edit request txeditreq initiated by a target node; the target node is any node in the initial blockchain; The voting unit is configured to write the target edit request txeditreq into the voting initiation contract through the target node, and determine the target VDF calculation times Teditreq corresponding to the target edit request txeditreq through the voting initiation contract; determine the nodes in the initial blockchain that have voting intentions, and obtain m nodes; m is a natural number; obtain the voting transaction of each of the m nodes through the voting contract, and obtain m voting transactions; each voting transaction includes a voting result and a VDF calculation result; the VDF calculation result is the result obtained by the nodes in the m nodes performing VDF calculation based on the first parameter set; determine whether the target edit request txeditreq is voted through based on the m voting transactions; The editing unit is configured to edit the initial blockchain based on a preset blockchain editing algorithm and the target editing request txeditreq to obtain a target blockchain when the target editing request txeditreq is voted through.

10. A computer-readable storage medium, characterized in that A computer program for electronic data exchange is stored, wherein the computer program enables a computer to execute the method according to any one of claims 1 to 8.

Images