Distributed Anonymous e-Voting Method Based on Smart Contract Authentication

Round 1

Reviewer 1 Report

The paper proposes a distributed anonymous e-voting system based on Ethereum, which utilizes non-interactive zero-knowledge proof and Merkle tree technology for anonymous authentication. The system uses smart contracts for anonymous voting and automatic vote counting, ensuring public verifiability and anti-tampering of the voting process. The proposed scheme guarantees the user's information security and voting rights and solves the problems of a single point of failure, data loss, and leakage brought by traditional methods.

 

Overall, the paper presents a comprehensive and well-designed solution to the challenges faced by traditional e-voting systems. The use of blockchain technology and smart contracts ensures transparency and eliminates the need for a trusted third party for vote counting. The combination of zero-knowledge proof and Merkle tree technology for anonymous authentication is a good approach to ensuring user privacy.

 

However, the paper lacks a thorough evaluation of the proposed system's performance, specifically its speed on the Ethereum network. It would be beneficial to have some performance metrics to assess the system's efficiency and scalability. Additionally, the paper could benefit from including some critical papers that discuss the limitations of implementing blockchain technology on permissionless blockchains such as Ethereum.

 

Overall, the paper provides a promising solution to the challenges of traditional e-voting systems, but some improvements could be made.

Author Response

Dear Reviewers.
Hello, thank you very much for reviewing my article in your busy schedule, your suggestion is very good, but I simulated the Ether on Ganaches, so then the test data may be different from the real Ether network. So I did not do it, I just described my method, I can add it next if needed. Thank you again for your thank you.

 

Author Response File: Author Response.docx

Reviewer 2 Report

This work proposes a blockchain technology-based voting record synchronization model and an anonymous authentication model, using ZK-snark and Merkle tree technology.

It is an overall interesting approach, and the authors are presenting an degree of substantial knowledge in the domain.

 

Still to the best of my efforts I did not manage to get a clear view of the overall architecture of the proposed solution (at least not up to section 4), while some key points of the proposed approach remained unclear to me:

Where are the “smart contracts” executed and when? What “triggers” them?

In my opinion, too many things are being presented and an in-depth analysis of those is attempted in this paper, while the overall schema of the solution was somehow unclear to me.

 

The authors are getting in and out of various details, making the integral flow hard for the reader to follow.

To the best of my effort, I often found myself “lost in the details”. In my opinion, an overall flow-chart and an integral architecture schema in some early stage (perhaps in the beginning of section 3) could be of most help to the reader.

To the best I can tell, the authors should go through a restructuring of their paper, to make it more comprehensive and to highlight their contribution.

Benchmarking data could also be of help to justify the applicability of the proposed method.

 

 

Specific Comments

 

Minor language issues detected (lines 68, 103, 184, etc.)

Line 127: Explain or omit allegation for specific country (Turkey).

 

In section 2.2 the authors are presenting some related work. Still, it would be helpful for the reader to state the contribution of their work comparatively: what others do not resolve (or resolve partially) that the authors do differently - better than them.

 

Line 190 “which first encodes/describes the problem for a specific problem” please rephrase.

 

Section 3.1

To the best of my knowledge, the authors are presenting the steps of their algorithm as a transformation of R1CS, to QAP via Langrage interpolation. Even though their approach is interesting, I found the math and the reasoning hard to follow. In my opinion the authors are attempting to get deeply into the detail of the math of the process, which makes it hard for the reader to follow the integral architecture and the flow of the proposed solution.

Perhaps the authors could provide brief description of each step of their algorithm in plain words (as for instance step 3, step 5, etc.)., so as to help the reader follow flow of the algorithm.

 

Figure 2 minor typo: “contraints” -> “ constraints ”

 

Line 314, justification is needed.

Lines 332-334: Reference to an overall architecture/flow schema – see general comments.

Lines 346-347: I believe that the authors should make this very clear in the very early sections of the manuscript, perhaps in an introductory section along with an overall flow/architectural schema.

 

In my opinion, it is obvious that a considerable effort was carried out by the authors. Still, I found the flow of the proposed solution hard to follow.

 

I propose the authors to go through a restructuring of the paper and include an integral architecture and flow diagram as well, before it is considered for publication. 

Author Response

Dear Reviewer.
Hello, thank you very much for reviewing my paper in your busy schedule, your suggestions are very good, have made specific changes according to the suggestions you provided, looking forward to the suggestions you can make to my paper again. Thank you again for reviewing my paper.

Round 2

Reviewer 2 Report

I would sugest the authors to submitt a detailed list of ammedments with respect to the previous comments before their work is considered for publication. 

Author Response

 

 

Author Response File: Author Response.pdf

Round 3

Reviewer 2 Report

The authors have gone comprehensively through their work.
I suggest it is accepted for publishing in its current form.

Author Response

 

 

Author Response File: Author Response.pdf