KR102430835B1 - Bolckchain e-voting system and manipulation method - Google Patents

Abstract

The blockchain electronic voting system of the present invention includes at least two voting nodes each having a private key and a public key; a control center that uploads the identification information of the voting node to the block chain; Receives the public and private keys and self-identification data of the voting node, identifies the voting node, generates an identification number, performs group encryption on the voting result, and generates zero-knowledge evidence that guarantees the fairness of the process 1 smart contract module; and a second smart contract module that downloads the voting results from the block chain and checks the fairness and counting results of voting without decrypting the voting results.

Description

Blockchain e-voting system, operation method of the system {Bolckchain e-voting system and manipulation method}

The present invention relates to an electronic voting system using a convex chain.

As an example, the present invention relates to an electronic voting system using a block chain capable of zero-knowledge proof that does not require a checker.

As an example, the present invention relates to an electronic voting system using a block chain based on a smart contract.

As an example, the present invention relates to a voting system based on a smart contract capable of zero-knowledge proof without the need for a voter.

The electronic voting system using the online system is economical and has the advantage of being able to express opinions anytime, anywhere. However, there is a disadvantage in that it is difficult to keep various basic principles of voting.

In this background, publication patent number 1020200008413 is known as an electronic voting system using a block chain and an operating method of the system. Although the feasibility of online voting has been improved by the above patent document, there is a problem that it largely depends on the reliability of the election commission. In view of the nature of electronic voting, relying on the credibility of the Election Commission becomes a big problem that makes it difficult to apply the electronic voting system in practice.

Specifically, the voting system of the patent document relies on a trusted third-party called the Election Commission. For example, the Election Commission keeps all of the voters' DIDs and voting rights data corresponding to each. Therefore, the election commission can use the voting rights of others. That is, the reliability of electronic voting may be damaged by the manipulation of the Election Commission.

In addition, if the election commission is a computer program and a server, the possibility that all records are stolen by hackers cannot be excluded.

In addition, the Election Commission may omit certain votes at will.

As we saw above, if the election commission, which operates on the basis of faith, is corrupted, it can lead to fraudulent voting. In particular, it is a big problem for non-governmental or private organizations with no public credibility.

Publication No. 1020200008413 (2020.01.28) 'Terminal device and server for performing electronic voting based on blockchain with guaranteed secret election, and electronic voting method'

The present invention proposes a blockchain electronic voting system that does not depend on the election management committee, and a method of operating the system as proposed in the background described above.

The blockchain electronic voting system of the present invention includes at least two voting nodes each having a self-identification private key and a self-identification public key and a group encryption private key and a group encryption public key; a control center for uploading self-identification data of voting nodes and the public keys to the block chain; By receiving the public and private keys and self-identification data of the voting node, identifying the voting node, generating an identification number, performing group encryption on the voting result, and generating zero-knowledge evidence that guarantees the fairness of the process a first smart contract module; and a second smart contract module that downloads the voting results from the block chain and checks the fairness and counting results of voting without decrypting the voting results.

The first smart contract module may upload the voting result and zero-knowledge evidence on which the group encryption has been performed to the block chain.

In the operating method of the blockchain electronic voting system of the present invention, the voting node generates a self-identification public key, a self-identification private key, a group encryption public key, and a group encryption private key; transmitting, by the voting node, a self-identification public key and a group encryption public key to the control center; uploading, by the control center, the self-identification public key, group encryption public key, and self-identification data of the voting node to the block chain; The voting node accesses the first smart contract module to identify itself by comparing the self-identification data it owns with the self-identification data uploaded to the block chain, and unique voting node identification using the self-identification public key Generating the number, generating the first zero-knowledge evidence that guarantees the fairness of the self-identification process and the uniqueness of the voting node identification number, writing one's own choice and performing group encryption, writing one's own choice generating second zero-knowledge evidence that guarantees the fairness of the process and the group encryption process; uploading, by the first smart contract module, the first zero-knowledge proof and the second zero-knowledge proof of the voting node to the block chain, and uploading the voting result of the voting node to the block chain; The second smart contract module examines the first zero-knowledge evidence and the second zero-knowledge evidence, and performs a check by synthesizing the voting results.

According to the present invention, it is possible to implement electronic voting that preserves the properties of voting, keeps zero-knowledge proof, and does not depend on the reliability of a third party such as an election commission.

1 is a block diagram of a block chain electronic voting system according to an embodiment.
Figure 2 is a flow chart explaining the operation method of the electronic voting system according to the embodiment.
Figure 3 is the upload data of the voting node uploaded to the blockchain.

Hereinafter, specific embodiments of the present invention will be described in detail with reference to the drawings. However, the spirit of the present invention is not limited to the following embodiments, and those skilled in the art who understand the spirit of the present invention can easily change other embodiments included within the scope of the same idea by adding, changing, deleting, and adding components. However, this will also be included within the scope of the present invention.

First, various technical elements used in the description of the embodiment of the present invention are defined.

<Blockchain>

Blockchain is a database that exists on the Internet peer-to-peer network. A blockchain consists of blocks connected to each other, and each block has multiple transactions. At least one of data and a smart contract is recorded in the transaction. Outside the block, there is a transaction pool waiting for verification. The verification-waiting transaction pool is a temporary storage for storing transactions that have not yet been verified. Data recorded on the blockchain cannot be forged or tampered with. There is no permission required to read data recorded on the blockchain. That is, anyone can access it.

The procedure for users to upload data to the blockchain goes through the stages of verification and publication (broadcasting) and is specifically as follows. First, after the user converts data into a transaction form, it is inserted into the transaction pool waiting for verification, and the transaction pool waiting for verification is shared. Multiple validators verify transactions in the transaction pool waiting to be verified. When the verification of the transaction waiting for verification is finished, the transaction waiting for verification is published in the block through consensus among the validators. If the blockchain used is a public blockchain, the validator is an unspecified number of miners, and in the case of a private blockchain, the validator may be a pre-selected blockchain administrator.

<Zero-Knowledge Proof>

Zero-knowledge proof is a proof protocol in which a prover convinces a verifier that a certain statement is true. In this case, the zero-knowledge proof protocol must have a zero-knowledge characteristic that does not transmit any information other than the fact that the proposition is true or false to the verifier.

When a proposition consisting of public and private information is S, a necessary and sufficient condition for a proof protocol to be a zero-knowledge proof protocol, completeness. soundness, and zero-knowledge.

The zero-knowledge proof protocol can be divided into two processes: a proof process and a verification process. The proof process is a process in which the prover verifies that the proposition S is true and then generates the evidence. The verification process is a process in which the verifier receives the evidence from the prover and confirms whether there is a problem in the evidence. If there is no problem with the evidence, it must be mathematically guaranteed that the prover performed the self-test of the proposition S well.

<Vote Node Identification Number>

Includes the signature algorithm used by voting nodes to generate identification numbers. Here, the voting node may be a resource that allows the voter to vote.

Examples of the signature algorithm may include Rivest-Shamir-Adleman (RSA) encryption and Elliptic Curve Digital Signature Algorithm (ECDSA) encryption. Other methods may also be applied.

In an embodiment, a signature algorithm utilizing RSA may be used. Described specifically.

Every voting node has a self-identifying public key of p, and q, and a self-identifying private key of s. Here, the key is required for generating the identification number of the voting node. The process (sign) of generating a unique identification number by signing the personal identification data m of the voting node can be defined as sing(m,s):=m ^s modq. The p, q, and s may be provided according to the RSA method using any two prime numbers.

The process of verifying that a certain identification number M is unique is verify(M,p,q):=(M ^p modq)^(mmodq), where ^ is an operator that outputs 1 if the two operands are the same and outputs 0 if they are different. . Since only one self-identifying public key for one voting node is uploaded to the blockchain, the verification process can prove the uniqueness of the voting node identification number.

<Group Encryption>

Group encryption is used to encrypt and validate votes. The group encryption is encryption that enables the collective calculation of voting results without decrypting the voting contents. The group encryption of the embodiment is only a predetermined example, and other methods are possible.

The process of group encryption in the embodiment will be described.

First, every voting node can have two group encryption public keys and one group encryption private key. Here, the key is required for group encryption. The i-th voting node among the voting nodes may have an arbitrary integer sk _i as a group encryption secret key. The i-th voting node may provide one group encryption public key (eg, pk _i :=g ^ski ) by using the secret key. Here, g is the encryption base of the group G of voting nodes that perform voting, and is information disclosed to all voting nodes. Group G is a group consisting of N voting nodes. The encryption base g is an integer. The encryption base may be provided from a control center.

Using the public key of all voting nodes, it is possible to provide another group encryption public key (yk _i ). Using Equation 1, it is possible to provide another public key yk _i of the i-th voting node.

Here, yk _i is another public key of the i-th voting node, pk _i is one public key of the i-th voting node, and N is the number of voting nodes belonging to the group G.

The group encryption (ENC) of the G group may be given by Equation (2).

Here, m _i is the message that the i-th voting node of group G wants to load, that is, the content of the decision.

Inspection may be performed by Equation (3).

Here, ENC _G(i) is the encrypted message of the i-th voting node of the G group.

The group encryption will be described as an example. There is a certain group of voters of three. i is from 1 to 3. Each voting node shares two public keys and one private key for group encryption. The encryption base is exemplified as 3.

,

, 및

로 할 수 있다. Each group member's public key and private key,

,

, and

can be done with

When the private key and public key of each group member are determined as described above, the group public key (yk _i ) of each group member can be generated using Equation 1 above.

,

, 및

가 될 수 있다.The group public key of each group member is,

,

, and

can be

Each group member's vote is a decision-making, and a score out of 5 is voted, and after the counting result, the perfect score is 15. Each group member voted, for example, with 2 points for m ₁ , 4 points for m ₂ , and 1 point for m ₃ .

Group encryption (ENC) of the i-th group member may be performed by Equation 2 above.

The group encryption result of each group member performed by Equation 2 is,

로 주어질 수 있다.

can be given as

로 집계됨을 알 수 있다. A checklist (or aggregation) may be given by Equation (3). When the check of each group member is performed using Equation 3,

It can be seen that counted as

In the end, the aggregate result is 3 ⁷ , and 7 is calculated by taking the discrete log with the base 3 (encryption base). According to this result, the intention of each voting node cannot be known because the result of group encryption is not decrypted during the counting process. Nevertheless, the voting results of the entire group can be known.

Of course, other methods may be used for group encryption applied in the embodiment.

<Smart Contract>

Smart contracts can be provided in the form of programs. After receiving the input and performing the specified operation, the output can be recorded and uploaded in a new transaction. The operations supported by the smart contract include all operations supported by the Turing-complete language, including those used in the zero-knowledge proof protocol. The resource on which the smart contract is performed may be referred to as a smart contract module. The smart contract may be provided by the control center.

In an embodiment, the smart contract module may include a first smart contract module that executes voting, and a second smart contract module that executes a ballot.

1 is a block diagram of a blockchain electronic voting system according to an embodiment.

Referring to FIG. 1 , the control center 2 may provide the password and base g of group G to each voting node (original character 1). The control center 2 obtains the public key of each voting node 1 (original character 2), and the identification information (DID: Digital ID, iris, and fingerprint of each voting node 1 held by the control center) etc.) and can be uploaded to the block chain 3 (original character 3). The control center 2 can upload the smart contract to the block chain 3 (original letter 3).

The first smart contract module 41 downloads information of all voting nodes (original character 4). The first smart contract module 41 connects to each voting node, and identifies the voter for each voter (voteID _i ), the zero-knowledge proof of the voter identification (proof_voteID _i ), and the voting content recording. have. The first smart contract module 41 may generate a group public key (yki), perform group encryption (ENC _G(i) (vote _i )), and perform zero-knowledge proof (proof_voteENCi) of group encryption.

The voting node (1) is connected to the smart contract module (41). The voting node 1 uploads, as a smart contract, the DID possessed by the voting node itself, a public key and a private key for signing, and a public key and a private key for group encryption (original letter 5).

The first smart contract module 41 uploads the voting result to the block chain 3 (original character 6). In the voting result (ballot _i ) of the i-th voting node, voter identification information (voteID _i ), zero-knowledge proof of the voter (proof_voteID _i ), voting execution time (time_publish), group public key (yki) generation, group encryption information (ENC _G(i) (vote _i )), and a zero-knowledge proof of group encryption (proof_voteENCi). A group public key is applied to the group encryption information. The group encryption information may contain the choice of the voting node.

After the voting has been completed, a ballot can be performed. Inspection may be performed by the second smart contract module 42 . The second smart contract module 42 obtains a secret key s0 for review from the control center 2 . The second smart contract module 42 may perform a review using the information contained in the block chain.

The second smart contract module recognizes only the most recent voting result (balloti) if there are two inputs marked with the same identification number. Through this, by using the latest information when a voting node voted twice, the true intention expressed by the voting node can be grasped.

The second smart contract module 42 can know the voting result without decoding the message. This has been described in detail through the group encryption.

An operating method of the blockchain electronic voting system according to an embodiment will be described with reference to FIG. 1 and related technical elements.

2 is a flowchart illustrating a method of operating an electronic voting system according to an embodiment.

The method of operation of the embodiment does not require a trusted validator. In the operating method of the embodiment, the voting characteristics do not depend on the credibility of a third party. The operation method of the embodiment includes a control center hosting a vote and a voting node participating in the voting. The control center may have its own secret key (s0) used for ticketing. Voting may be a procedure of asking the votes of the voting nodes and synthesizing the results based on the agenda defined by the control center in advance and the decision options related thereto. A voting node can give multiple votes to one doctor. The number of votes one voter can cast may be limited to a maximum of S _max . The number of voters is N, and the list of voters may be determined before the voting takes place. Organizers can retain all voters' personal authentication data before voting takes place. The voter's personal authentication data held by the organizer can be called S-DIDi. Examples of personal authentication data may be at least one of an iris image, a fingerprint image, an ID photo image, voice data, and public authentication data, but is not limited thereto. For N voters, the voter's personal authentication data may be referred to as DIDi. The operation method of the embodiment may upload the zero-knowledge evidence to the blockchain after the voting node performs self-verification for the fairness of all voting processes.

First, the control center 2 may provide the encryption and the base g to each voting node (S1). The voting node 1 may generate a public key (pi, qi) and a private key (si) for signing. The voting node 1 may generate a public key (pki) and a private key (ski) for group encryption using the encryption base g. The voting node may transmit the public key to the control center (S2).

The control center 2 may upload the data of each voting node to the block chain 3 as shown in FIG. 3 (S3). Other data uploaded to the block chain 3 may also be uploaded in the same structure although the content is different.

The control center 2 may upload a smart contract (S3). The smart contract may include a contract for voting and a contract for review. In the data of the voting node, identification information (DID: Digital ID) of each voting node 1 previously held by the control center may be uploaded.

Voting may be performed by the first smart contract module 41 . The table node may vote by using the first smart contract module 41 .

The first smart contract module 41 connects with each voting node, identifies each voting node to generate a unique identification number, and the process of creating a choice of each voting node can be performed ( S4). Zero-knowledge proof may be performed for the generation of the identification number and the creation of the pseudo-option.

More specifically, verifying the voting node by comparing the identification information of each voting node (Cert), the identification of the corresponding voting node for each voter (voteIDi), the zero-knowledge proof of the corresponding voting node (proof_voteID), and voting contents Recording (x input) can be performed.

Here, one last field (L+1) may be added to the voting contents. If the additional field is not zero, it may be treated as an abstention vote later. Through this, the voting node may vote for an abstention vote.

Thereafter, it may be determined whether the sum of the field values does not exceed the maximum value Smax. If the sum of the respective field values exceeds the maximum value, it may be invalidated as an abnormality.

Thereafter, it is possible to generate the group public key (yki), perform group encryption using the group public key (ENC), and perform zero-knowledge proof (proof_voteENC) of the group encryption.

After that, if zero occurs in any one of the last confirmation of the voting node (Cert), the zero-knowledge proof (proof_voteID) of the corresponding voting node, and the zero-knowledge proof (proof_voteENC) of the group encryption, it is treated as an error and can be redone. A number of votes may be held.

When voting ends normally, personal identification information (DIDi) and secret key (si, ski) are deleted.

When voting ends, the first smart contract module 41 uploads predetermined information to the block chain 3 (S5). The uploaded information includes voter identification information (voteIDi), zero-knowledge proof of the voter (proof_voteID), voting execution time (time_publish), group public key (yki) generation, group encryption information (ENC _G(i) (votei)) , and a zero-knowledge proof of group encryption (proof_voteENCi) may be included.

The voting process (S4) and the voting result uploading process (S5) are performed by the first smart contract module, and for details, refer to Equation (4).

In Equation 4, ZKP (operation) is a function for generating zero-knowledge evidence that guarantees the fairness of the operation process of the input operation.

In Equation 4, ZKP_verify (evidence) is a function that verifies the validity of the input zero-knowledge evidence.

After the voting of all voting nodes is finished, the ballot can be performed.

Inspection may be performed by the second smart contract module 42 . The second smart contract module 42 may obtain the secret key s0 for review and the information contained in the block chain from the control center 2 (S6).

The second smart contract module 42 may reject the check if the secret key (s0) it owns and the secret key obtained are different from each other.

The second smart contract module 42 may obtain information through the block chain and find out the information contained therein. In this case, the information may mean generating a single piece of information by linking the information of each block of the block chain. In this case, the information may not mean individually decrypting the encrypted group encryption information.

The second smart contract module 42 may find out the aggregation result of the pseudo option without decrypting the pseudo option (S7). As described above, the above operation is performed by the group encryption.

The second smart contract module 42 performs verification of the zero-knowledge proof (proof_voteIDi) of the corresponding voting node (ZKP_verify(proof_voteIDi)) and the verification of the zero-knowledge proof (proof_voteENCi) of the group encryption (ZKP_verify(proof_voteENCi)) can be done

The second smart contract module uses the most recent voting result (balloti) if there are two inputs for the same voter. Through this, it is possible to grasp the true intention of a voting node by using the best information when a voting node has voted twice.

Thereafter, the second smart contract module 42 may upload the aggregate result to the block chain 3 (S8).

The voting characteristics that the voting system should have are as follows.

Accuracy: All valid valid votes are counted accurately in the voting results.

Verification: A means of verifying voting results is required to prevent forgery of voting results.

Integrity: Blocking interference by fraudulent voters and uncounted fraudulent votes.

Unity: Non-voting voters are not allowed to vote.

Legality: A valid voter can only participate once.

Confidentiality: Ensuring the confidentiality of voters and voting results.

Fairness: The result of the count during voting does not affect the remaining votes.

The system and operating method of the present invention will be described in keeping each of the above characteristics.

First, factors that guarantee the accuracy can be exemplified as follows.

Voters can self-verify the validity of their votes using the voting smart contract. Evidence of performing self-validation of the validity of the vote can be generated. Evidence of voting validity can be verified by an unspecified number of blockchain validators (miners). The checklist smart contract module can verify the validity of the vote once more. Verified evidence and encrypted votes are recorded together on the blockchain and can be immutable. All votes can be aggregated collectively by the ticketing smart contract.

Factors that ensure the confirmability can be exemplified as follows.

Evidence that the content of the vote was written by the voter is recorded on the blockchain along with the encrypted voting data, making it immutable. If the voting data is manipulated, the verification of the evidence is impossible, so it can be treated as an invalid vote. Anyone can reproduce the aggregated results after verifying the voting data and evidence.

Factors that ensure the above integrity can be exemplified as follows.

Every voter can self-verify that it is a legal vote after writing the vote and record the evidence on the blockchain. If the voting contents are false, the evidence may be unverifiable. Votes recorded with unverifiable evidence may be invalidated.

Factors that ensure the unity can be exemplified as follows.

All voters can self-certify and record the evidence on the blockchain together with the votes. If the personal authentication evidence cannot be verified, the votes recorded together may be invalidated.

Factors that ensure the above legality can be exemplified as follows.

Each voter has a unique physician option identification number. The pseudo-option identification number is generated using the voter's private key and may need to be verifiable using the pre-registered voter's public key. Since one voter pre-registers only one public key, one voter can generate only one identification number. Voters can self-validate the validity of the identification number using their public key, generate the evidence, and record it on the blockchain along with the identification number. If the evidence as to the validity of the identification number cannot be verified, the votes recorded together may be invalidated.

Factors that ensure the confidentiality can be exemplified as follows.

Voters can directly generate a pseudo-selection identification number using their private key. Since the voter records only the pseudo-selection identification number in the blockchain, a third party who does not know the secret key cannot infer the relationship between the voter and the identification number. Since the contents of the votes are encrypted and disclosed, and the contents are not decrypted even when the ticket is counted and counted, a third party cannot infer the relationship between the identification number and the contents of the vote.

Factors that ensure the fairness can be exemplified as follows.

All voting contents can be encrypted and uploaded. Voting contents may not be decrypted throughout the entire voting process, including the counting and counting. If all votes are not completed by group encryption, it may not be possible to count votes.

According to the above content, the advantages of the present invention voting system and its operating method can be understood.

According to the present invention, it is possible to maintain the zero-knowledge proof and operate the electronic voting system in a state that is not affected by the reliability of a third party.

1: Voting node
2: control sensor
3: Blockchain
41, 42: smart contract module

Claims (20)

at least two voting nodes each having a private key and a public key;
a control center that provides an encryption base to the voting node;
The voting node receives a public key and a private key for group encryption generated using the encryption base, and performs group encryption on the voting of the voting node,
To upload the voting results on which the group encryption has been performed to the blockchain,
a first smart contract module in which a smart contract is performed; and
A second smart contract module that downloads the voting results from the block chain and checks the voting results without decrypting the voting results is included,
The first smart contract module is a block chain electronic voting system that uploads a voting execution time (time_publish) to the block chain. The method of claim 1,
The control center pre-records the first personal identification information of the voting node and uploads it to the block chain,
The voting node uploads the second personal identification information it has to the first smart contract module,
The first smart contract module is a block-chain electronic voting system that confirms the voting node by comparing the first and second personal identification information. The method of claim 1,
A block chain electronic voting system in which the control center provides a secret key for ticketing to the second smart contract module. The method of claim 1,
The first smart contract module is a blockchain electronic voting system that performs voting node identification (voteIDi) for the voting node, and zero-knowledge proof (proof_voteID) for voting node identification. The method of claim 1,
The first smart contract module is a blockchain electronic voting system that performs zero-knowledge proof (proof_voteENCi) of the group encryption. The method of claim 1,
The smart contract is a block chain electronic voting system that the control center supplies through a block chain. The method of claim 1,
The first smart contract module includes voting node identification information (voteIDi), zero-knowledge proof of voting node identification information (proof_voteID), group encryption information (ENC _G(i) (votei)), and zero-knowledge proof of group encryption information A blockchain electronic voting system that uploads (proof_voteENCi) to the blockchain. The method of claim 1,
The second smart contract module is a block chain electronic voting system that uploads the counting result to the block chain. The method of claim 1,
The second smart contract module is a block chain electronic voting system that uploads the counting result to the block chain. that the control center provides the same cryptographic base to each of the at least two voting nodes;
generating, by the voting node, a public key (pki) and a private key (ski) for group encryption using the encryption base;
transmitting the public key to the control center by the voting node;
uploading, by the control center, the data of the voting node to the block chain;
The voting node accesses the first smart contract module, identifies and signs itself, writes its own choice and performs group encryption;
uploading, by the first smart contract module, a voting result to the block chain;
It is performed that the second smart contract module performs the check,
The information uploaded to the block chain by the first smart contract module includes a voting execution time (time_publish). 11. The method of claim 10,
The voting node generates a public key (pi, qi) and a private key (si) for signing, and transmits it to the control center and the first smart contract module. A method of operating a blockchain electronic voting system. 11. The method of claim 10,
The smart contract of the first and second smart contract modules is a method of operating a block chain electronic voting system that the control center uploads to the block chain. 11. The method of claim 10,
The data of the voting node includes identification information of each voting node previously held by the control center,
The voting node transmits its identification information to the first smart contract module,
The first smart contract module, the operation method of the blockchain electronic voting system, in which the verification of the voting node by comparing the two identification information is performed. 11. The method of claim 10,
The method of operating a blockchain electronic voting system, wherein the voting node accesses the first smart contract module, and zero-knowledge proof for the signature work and zero-knowledge proof for the pseudo-choice work are further performed. 11. The method of claim 10,
The operation method of the block chain electronic voting system in which one field for identifying the abstention vote is further added to the decision option. 11. The method of claim 10,
After the end of voting, personal identification information (DIDi) and secret key (si, ski) are deleted. How to operate a blockchain electronic voting system. delete 11. The method of claim 10,
The second smart contract module is a method of operating a block chain electronic voting system to obtain a secret key (s0) for ticketing from the control center. 11. The method of claim 10,
The second smart contract module is a block that performs verification (ZKP_verify(proof_voteIDi)) of the zero-knowledge proof (proof_voteIDi) of the corresponding voting node and verification of the zero-knowledge proof (proof_voteENCi) of the group encryption (ZKP_verify(proof_voteENCi)) How to operate the chain electronic voting system. 11. The method of claim 10,
A method of operating a block chain electronic voting system in which the block chain uploads the second smart contract check result.

Images