Keywords

1 Introduction

With the goal to minimize the expense and maximize the efficiency of executing an election, it is becoming increasingly difficult to ignore the security, privacy and compliance when designing electronic voting systems [11]. For this purpose, in the area of e-voting system, there has been a recent surge in interest and research. However, security, transparency, distributed authority, data integrity, privacy and compliance requirements have become the main bottlenecks blocking e-voting systems implemented on a large scale [30].

In order to counter the bottlenecks that mentioned above, a promising data structure known as blockchain is initially introduced to e-voting systems. In essence, blockchain is a distributed ledger that has the property of tamper-resistance. That is, the blockchain’s database is maintained by each node on chain rather than single node which leads to blockchain be the immutable ledger with transactions in old blocks preserved and transactions in new blocks irreversibly added [19].

With regard to the e-voting systems proposed for implementation using the blockchain technology, a series of requirements and features are summarized to build proper schemes in [28].

  1. 1.

    textbfReceipt-freeness [4]: Any evidence proving the voter’s selection for a particular candidate is not allowed to be revealed.

  2. 2.

    Fairness [6, 9]: Every voter should have the same weight when taking part in the voting.

  3. 3.

    Data integrity [12]: Each valid vote is recorded correctly and can’t be tampered with by any part, once logged.

  4. 4.

    Privacy [33]: The anonymity of voters should be guaranteed.

  5. 5.

    Eligibility [22]: The system only accepts the registered voter’s ballot.

  6. 6.

    Reliability [8]: The system is stable and no vote is missed.

  7. 7.

    Uniqueness [24]: Double voting is not allowed.

  8. 8.

    Verifiability [16]: Voters have the right to verify whether their ballots are tallied legitimately.

According to the features and requirements that mentioned above, cryptography is considered as one of the most effective technologies that can be utilized to e-voting systems. On one hand, in order to achieve the goal of verifying the trustworthiness of the administrator without information disclosure, zero-knowledge proof is one of the most widely used cryptographic primitives and plays a key role in the field of privacy protection. On the other hand, additively homomorphic encryption has the features that only supports arithmetic for elements of its plaintext space and provides an operation that produces the encryption of the sum of two numbers, given only the encryptions of the numbers [10]. Consequently, it can be effectively applied to e-voting systems that focuses on data confidentiality. In our work, combining these two cryptographic technologies enables us to realize a majority of the above-mentioned requirements relating to information security including receipt-freeness, privacy and verifiability. Whereas, data integrity and reliability relies on the immutability of blockchain and fairness, eligibility and uniqueness is based on the implementation of software system by utilizing solidity and python.

The rest of this paper is organized as follows. Section 2 presents related work and Sect. 3 introduces some fundamental technologies as preliminaries. Section 4 represents our proposed e-voting system, and Sect. 5 shows the performance evaluation of our system from the perspective of time performance and gas fee performance. Finally, Sect. 6 concludes the paper.

2 Related Work

The existing e-voting schemes that blockchain is applied to are classified into two types: blockchain-based e-voting system and e-voting system using blockchain.

2.1 Blockchain-Based E-Voting System

In the blockchain-based e-voting system, the whole system is built upon the blockchain framework. In other words, blockchain is convinced to be the infrastructure that sustains the system. Most of the blockchain-based e-voting system adopt the permissioned blockchain structure instead of permissionless blockchains such as Bitcoin and Ethereum.

In [11], the authors propose a blockchain-based e-voting system based on a permissioned blockchain, and some of the popular blockchain frameworks are evaluated for constructing a blockchain-based e-voting system. Sun et al. propose a simple voting protocol based on the existing Quantum Blockchain [13, 25]. It satisfies the most important properties of secure voting protocols by introducing matrix and number theory to the stages of ballot commitment and ballot tallying [24]. In addition, a blockchain-enabled large-scale e-voting system with robustness and universal verifiability is presented in [32]. In this system, a hybrid approach which combines the counting bloom filter and Merkle hash tree is developed in order to break the bottleneck of cost performance.

Generally speaking, this kind of e-voting systems has the merits of cost-friendly performance and high response rate. However, a major problem with this approach is utilizing the permissioned blockchain as the blockchain framework of the system, leading to lower reliability for voters. In particular, most of the nodes in the system are maintained by the administrator, making it more difficult for voters to verify the fidelity of the administrator. This verification by voters is one of our goals.

2.2 E-Voting System Using Blockchain

Referring to the relation between Infrastructure-as-a-service (Iaas) and Platform-as-a-service (Paas) (two kinds of cloud service delivery models) in cloud computing [5], the blockchain in this kind of e-voting system acts as the platform rather than the infrastructure compared with that in blockchain-based e-voting systems. For this reason, this kind of systems mainly focuses on smart contract provided by the blockchain. Consequently, Ethereum is convinced to be one of the most suitable blockchain frameworks for this kind of systems due to its reliability and functionality.

The authors of [31] present a platform-independent secure and verifiable voting system combining with a variety of cryptographic techniques including Paillier cryptosystem that supports the execution of a smart contract. In [18], Lyu et al. propose a trustless e-voting system, which is deployed on Ethereum by smart contract. The authors use linkable ring signature [7, 14, 15] and threshold encryption without a trusted third party in their system. Except for these e-voting systems focusing on security and privacy by cryptography, some other systems concentrating on the countermeasure for the low efficiency and expensive cost also utilize blockchain as the platform. Based on web3 framework and POA network, Al-Madani et al. make their system to support real-time service without using any cryptosystem [3].

In contrast to blockchain-based e-voting systems, e-voting systems using blockchain are commonly doubted due to the higher expense. However, this kind of systems has great reliability because of introducing the existing famous blockchain framework (e.g. Ethereum). For this reason, we design our system based on the criterion that is similar to e-voting systems using blockchain.

3 Preliminaries

3.1 Smart Contract

In order to minimize contracting cost between transacting parties and to avoid accidental exceptions or malicious actions during contract performance, Nick Szabo suggested translating the clauses of a contract into code and embedding them into software or hardware to make them self-execute, which is known as smart contract [27, 34].

As a program running on a blockchain, a smart contract can be correctly executed by a network of mutually distrusting nodes without the need of an external trusted authority. The self-executing nature of smart contracts provides a tremendous opportunity for use in many fields that rely on data to drive transactions [26].

Blockchains can be divided into permissioned blockchains (i.e. non-public) and permissionless blockchains (i.e. public). Permissionless blockchain platforms allow any user to join the network while permissioned blockchain platforms allow only permitted users to join [34]. Different blockchain platforms provide different support for smart contracts. Some (e.g. Bitcoin) may only allow users to use a simple scripting language to develop smart contracts with simple logic; while some platforms, such as Ethereum, support much more advanced programming languages for writing smart contracts [23].

3.2 Homomorphic Encryption

An encryption is homomorphic if from Enc(a) and Enc(b), it is possible to compute Enc(f(a, b)) where Enc(x) represents the encryption of x and f is \(+\), \(\times \), or \(\oplus \) (exclusive OR) and without using the private key for decryption [29].

Homomorphic encryption can be categorized into three types of schemes with respect to the number of allowed operations on the encrypted data; (1) Partially Homomorphic Encryption (PHE), which allows only one type of operation with an unlimited number of times (i.e., no bound on the number of usages), (2) Somewhat Homomorphic Encryption (SWHE), which allows some types of operations a limited number of times, and. (3) Fully Homomorphic Encryption (FHE), which allows an unlimited number of operations for an unlimited number of times [1].

Paillier encryption is classified as Partially Homomorphic Encryption. In detail, it is an additively homomorphic encryption scheme based on composite degree residuosity classes. Paillier encryption is provably secure under appropriate assumptions in the standard model [20]. Simultaneously, Paillier encryption is proved to have the additive homomorphism so that it can be appropriately applied to e-voting systems because of the massive utilizing of add operation in these systems.

3.3 Zero-Knowledge Proof

Roughly speaking, the zero-knowledge proof realizes a scenario that a prover who wants to convince a verifier that some statement is true without revealing any other information.

As the applications, privacy-preserving systems use zero-knowledge proofs to prove the correctness of outputs without revealing sensitive information about inputs. In online voting systems, voters prove that they correctly encrypted their vote, without revealing any information about the selected candidate [2].

The authors of [17] propose zksk, a well-documented Python library for defining and computing sigma protocols (the most popular class of zero-knowledge proofs). In zksk, smaller proofs can be converted into building blocks that then can be combined into bigger proofs. In addition, compared with the large size of key and proof of traditional zero-knowledge proofs such as zk-SNARKs, zksk is more practical in some areas due to its smaller data size as low as several bytes.

4 Proposed System

This section describes the proposed smart contract-based e-voting system using partially homomorphic encryption and non-interactive zero-knowledge proof. Furthermore, oracle is another crucial technology applied to this system so that data privacy in the Ethereum-based smart contract is feasible to be guaranteed against external homomorphism attackers and internal untrusted entities.

4.1 System Components

The roles of users that participate the voting system are classified into three types: administrator, voter, and observer. The administrator and voter are indispensable for the voting system and have their own nodes, whereas the observer is optional and is not compulsively required to have a node in Ethereum. Moreover, the voter who tries to verify the zero-knowledge proofs associated with other voters is also regarded as an observer. The definitions of the three roles are as follows.

  1. 1.

    textbfAdministrator: The entity which is set up to manage and maintain the whole process of voting. The administrator’s work includes managing voter registration, initializing voter identity, creating smart contracts for the election, verifying ballots from voters, generating zero-knowledge proof, transmitting processed data to the oracle node, and announcing the voting result.

  2. 2.

    Voter: The entity which is eligible to act as a participant in the democratic election process. Valid ballots from voters are the essential component that results in formal voting. It is feasible for voters to register in the system using their identifiers such as Ethereum addresses, request the public key published in the blockchain, cast ballots in the smart contract, and verify the corresponding zero-knowledge proof which reveals their own identities.

  3. 3.

    Observer: The entity which is an extra part of the system roles to assure the feasibility and availability of the system. Observers are required to verify the zero-knowledge proofs of each voter and publish the verification result individually so that the public can decide whether the result published by the administrator is trusted or not.

We adopt smart contracts for implementing our voting system. The system has three types of smart contracts: Contract Voting, Contract VID, and Contract ZKP. The Contract Voting provides the functions of casting the ballot and processing the original voting data. Contract VID is used for publishing all voter IDs. Contract ZKP provides the functions of zero-knowledge proof for observers and voters. The details of the smart contracts are as follows.

  1. 1.

    Contract Voting: The Contract Voting manages the voters’ identifiers and announces the administrator’s public key to the eligible voters. The voters’ identifiers are registered in the address array type named “Alist”. The administrator verifies the eligibility of a voter by checking his/her identifier in Alist. If the administrator authenticates the voter as an eligible voter, the administrator announces his/her public key to the voter with a function of “announce_PK”. When the voter casts a ballot, the administrator verifies his/her voting data with the function of “verify_ballot”.

  2. 2.

    Contract VID: The Contract VID manages the identifiers of the voters whose ballots are verified to be valid and publishes them without revealing voters’ privacy. All voters’ identifiers are stored in a string array type called “VID_list”. At the stage of result announcing, any voter and observer can call the function named “return_VID” to acquire all voters’ identifiers.

  3. 3.

    Contract ZKP: The Contract ZKP manages the zero-knowledge proofs according to ballots that have been verified to be valid and allows the voter to retrieve his/her corresponding proof and verification key. A parameter in the type of string of “ZKP” is utilized to request zero-knowledge proof data downloaded from the server via oracle. When a voter wants to search the corresponding zero-knowledge proof, he/she can get the result with a function known as “search_ZKP” as long as the valid address is provided.

The data format of a vote is the encoding of its ballot. Due to the application of partially homomorphic encryption in this system, the form of voting data is designed to be compatible with it. After generating his/her voting data of which detail will be described in the following part, each voter encrypts the voting data with the public key of the administrator using Paillier encryption.

Let M and N denote the number of candidates and that of voters, respectively. We define the following variables for encoding.

  • We define Voted_ballot(j) (\(j\in \{1,\ldots ,N\}\)) as voter j’s selection among candidates. If voter j votes for candidate \(i\in \{1,\ldots ,M\}\), Voted_ballot(j) is set to

    $$ \text{ Voted }\_\text{ ballot }(j)=(10^8)^{i-1}. $$

    For example, consider candidates A and B are indexed with 1 and 2, respectively. If voter j votes for candidate A (resp. B), Voted_ballot(j) is set to 1 (resp. 100,000,000). Here, we set the interval of \(10^8\) for balancing the data size and the scalability.

  • Voter_address(j) is the voter j’s address in the blockchain network. For example, in Ethereum, if voter j’s address is 0xeC2804Dd9B992C10396b5Af176f06 923d984D90e, this value is substituted to Voter_address(j).

  • Each voter has his/her own unique voter ID which is generated by the administrator at the voter registration stage. Let Voter_ID(j) denote the ID of voter j. The administrator randomly generates a number from 1 to 99,999,999 for each voter who passed the identity verification and distributes it to the corresponding voter privately. Consider the case of 100,000,000 voter’s participation. Assuming the extreme situation that all of them vote for A, the resulting sum of the Voted_ballot is 100,000,000. Under this condition, we are unable to distinguish the situations that whether there is one voter voting for B or there are 100,000,000 voters voting for A except for additional verification. In order to avoid these matters, we set the maximum capacity of voters to be 99,999,999 and correspondingly make sure that all of voter’s ID are in the range from 1 to 99,999,999. Each voter knows his/her own voter ID, and the administrator can check the mapping relation between the voter’s address and voter ID.

  • At voting, each voter generates his/her own voting data. We define Voting_data(j) as the voting data of voter j, which is given by

    $$\begin{aligned}{} & {} \text{ Voting }\_\text{ data }(j) =\\{} & {} \,\,\text{ Voted }\_\text{ ballot }(j) + \text{ Voter }\_\text{ address }(j) + \text{ Voter }\_\text{ ID }(j). \end{aligned}$$

    Each voter calculates his/her Voting_data, encrypts the Voting_data as the ballot and sends it to the Contract Voting for voting.

The voting data processing for the administrator is classified into three task types. The first task type is retrieving the voting data array and address array from Contract Voting, then the administrator will rebuild these two arrays and generate an aggregated list consisting of the voter ID, voting data, and zero-knowledge proof. The second task type is verifying the validity of each ballot and generating the zero-knowledge proof for the voters whose ballots are verified to be valid. Last but not least, the list containing information processed in the former two steps is uploaded to a web page in json type deployed in our server built up for the oracle node to achieve data.

Fig. 1.
figure 1

Overview of the System.

Full size image

4.2 System Model

Figure 1 illustrates the overview of this system. The procedures included in our system are (1) voter registration, (2) system initialization, (3) contract creation, (4) voting, (5) ballot verification, (6) ballot tallying and result announcing, (7) zero-knowledge proof verification, (8) trustworthiness verification. The functions of each procedure are as follows.

  1. 1.

    Voter registration: The registration is held by the administrator and aims to sign up the eligible users and distribute the voter IDs. In detail, the administrator can authenticate the voter identity in two methods in accordance with the authentication site: on-site authentication and online authentication. In on-site authentication, the administrator directly authenticate the valid identity certificate of participants face to face. As soon as authentication finished, the administrator informs the corresponding voter ID to the voter. In the other case, with the help of technologies including blockchain and encryption, the system assures that the voter’s identity is authenticated and the voter ID is distributed in a private channel which is independent of the blockchain.

  2. 2.

    System initialization: The administrator processes the information received in voter registration and transforms it into arrays that can be used in the following procedures. On the one hand, the administrator creates an “Alist” containing all voters’ addresses and uploads it to contract Voting. On the other hand, the administrator generates a mapping list called “Mlist” that maps the voter’s address to the voter ID according to voter registration, and saves it privately and locally.

  3. 3.

    Contract creation: In this step, the smart contracts mentioned in Subsect. 4.1 are instantiated and deployed to Ethereum. Except for the instantiation and deployment, the administrator collects the addresses of these contracts from Ethereum and publishes them to voters.

  4. 4.

    Voting: Voting is the interactive process between contract Voting and voters, and is considered as a core operation in this system. In advance, voters are required to calculate their voting data in plaintext. Then, without the participation of the administrator, the voter calls the function “announce_PK” to obtain the administrator’s public key based on Paillier encryption. Furthermore, voters encrypt the voting data and upload them to contract Voting.

  5. 5.

    Ballot verification: Ballot verification is comprised of two stages: verification by contract and verification by the administrator. When contract Voting receives the encrypted voting data, it automatically verifies whether the address that the data come from is registered and whether there is any voter who casts the ballot more than one time. The ballots that do not satisfy the two conditions are discarded. The ballots that are not discarded in the first stage are then verified by the administrator for the correctness of the original voting data. The administrator decrypts the voting data in ciphertext and judges the decrypted voting data using “Mlist”. Ballots satisfying the conditions in both two stages are judged as valid.

  6. 6.

    Ballot tallying and result announcing: When the process of voting ends, the administrator collects all valid ballots and adds their voting data in ciphertext together to calculate \(m_{sum}\), which is given by

    $$ m_{sum} = \sum _{j\in \mathcal {N}_{vb}}\text{ Voting }\_\text{ data }(j), $$

    where \(\mathcal {N}_{vb}\) is the index set of the voters whose ballots are judged as valid. Then, the administrator decrypts \(m_{sum}\) and gains the result which can represent the voting result by the following formula

    $$\begin{aligned}{} & {} \text{ Result } =\\{} & {} \,\, m_{sum} - \sum _{j\in \mathcal {N}_{vb}} \left\{ \text{ Voter }\_\text{ address }(j) + \text{ Voter }\_\text{ ID }(j)\right\} . \end{aligned}$$

    Then, the administrator conducts vote counting and announces the winner on the official platform.

  7. 7.

    Zero-knowledge proof verification: In this system, we apply a non-interactive zero-knowledge proof proposal called “zksk” [17] as the method of zero-knowledge proof. The proof is generated just after the ballot is verified as valid at both the two stages. Here, each voter’s ID is kept secret. The detailed operations of the prover (the administrator) is illustrated in Algorithm 1.

    figure a

    When the zero-knowledge proof has been generated according to the above algorithm, the administrator uploads it to contract ZKP which is mapped to the voter’s address. The voter or any observer can access the proof with the specific address through the calling of contract ZKP. Then, they conduct Algorithm 2 to verify the proof.

    figure b

    If a voter verifies the proof associated with him/her successfully, he/she can trust that his/her ballot is tallied correctly. On the other hand, an observer can verify the proof of any address to check whether there is any extra ballot falsified by the administrator.

  8. 8.

    Trustworthiness verification: The procedure of trustworthiness verification is executed to verify the fidelity of the administrator from a different aspect with zero-knowledge proof verification. The observer utilizes \(m_{sum}\) in procedure 6 and does reverse operations to check whether the administrator revised the result. The verification process is shown in Algorithm 3.

    figure c

4.3 System Features

Based on the system components and system model, a slice of features are clarified. In our work, one of the most popular permissionless blockchains known as Ethereum is applied as the blockchain framework of the system so that reliability and robustness of the system is ensured by the stability of Ethereum and smart contract themselves.

As mentioned in Subsect. 4.2, we utilize a succinct zero-knowledge proof known as “zksk”. In comparison with other non-interactive zero-knowledge proofs (e.g. zk-SNARK), the size of zksk’s proving key and verification key is smaller and can be recorded in a parameter in string type. Thus, zksk is firmly convinced to be extremely compatible with this system rather than many other non-interactive zero-knowledge proofs due to the increasing cost according to data size when using oracle. Consequently, the application of zksk confirms the verifiability ensuring the voter’s right to learn that his/her ballot has been correctly tallied.

The voter’s privacy is assured by utilizing Paillier encryption, which is also known as an additively homomorphic encryption algorithm. The correctness of the formula that used to check whether the administrator revises the result is based on the additively homomorphism of Paillier cryptosystem.

In addition, receipt-freeness, fairness, data integrity, and uniqueness are ensured by the system structure which has been introduced in Subsect. 4.2. In detail, receipt-freeness and fairness are decided by the procedures including voter registration, voting, and ballot verification whereas data integrity and uniqueness are based on the verification process executed in ballot verification procedure.

5 Performance Evaluation

5.1 Experiment Environment

As explained in Subsect. 4.3, we apply Ethereum to the development of the proposed system, which is a permissionless blockchain as the blockchain infrastructure. Due to the cost saving, we utilize a local Ethereum blockchain known as Ganache to simulate transactions on Ethereum.

In our work, we implement the system in Python and Solidity. The functions described in Subsect. 4.1 are written in solidity. The remaining functions including zero-knowledge generation, server command, the second stage of ballot verification are realized by Python.

In order to enhance the connection between on-chain environment and off-chain environment and to upload zero-knowledge proof to contract ZKP, we select Provable [21] as the oracle in our system. With the merit of low cost and high response speed, Provable is feasible when applied in our system. In Ganache experiment environment, we set up a Ethereum bridge that allows Provable to be utilized to the testnet.

For evaluating the performance of the system, we run voter client, administrator client, and ganache client in the PC with Intel Pentium 4415U CPU, NVIDIA GeForce 940MX GPU, and ADATA DDR4 2666 12G RAM.

5.2 Execution Time Performance

In this subsection, we investigate the component-wise execution-time performance of the proposed voting system in order to figure out the time consumption of the whole system and which function takes over most of the time.

The functions measured in this experiment are: loading ZKP, loading VID, generating ZKP, processing data on administrator side, voting (successful), voting (double voting), voting (not in Alist), encrypting data, and decrypting data. Table 1 illustrates the execution time performance of each function under the condition of one voter’s participation.

Table 1. Execution time performance.
Full size table

In Table 1, loading ZKP takes over most of the time, which exceeds 50\(\%\) of the whole executing time. Following loading ZKP, the execution times of loading VID and generating key are around 2 s. The execution time of voting in case of a valid ballot is over 1 s, while the execution times of voting in cases of double voting and not-in-Alist are smaller than that of valid voting. The reason for this result is that loading operation in smart contract needs to send VIDs and zero-knowledge proofs from the off-chain environment to the on-chain environment using oracle. Therefore, it takes a lot of time for data exchange among different environments. Meanwhile, generating keys and voting also take more time than other operations due to the complicated cryptographic algorithm in them. According to the analysis, we have two conclusions. First of all, the whole execution time when casting per ballot is about 1.438 s to 2.243 s, which is better than a majority of existing systems that have been investigated on. What’s more, the operations executed by smart contract are the main reasons that result in low efficiency.

Fig. 2.
figure 2

Generating Zero-knowledge Proof.

Full size image

Generating zero-knowledge proof is regarded as the most core part of this system. Figure 2 demonstrates the total execution time for generating zero-knowledge proof in cases of the number of voters participating the system equal to 1, 100, 200, 300, 400 and 500. With up to 500 voters’ participation, our system has the ability to support zero-knowledge generating within 1.5 s, which is fast enough for a large-scale election at the present stage. Meanwhile, this experiment proves that the proposed voting system exhibits good scalability performance since the time for generating zero-knowledge proof is proportional to the number of voters.

5.3 Gas Fee

In this subsection, we investigate how much gas fee of Ethereum is needed for the proposed voting system. We measure gas fee of the following functions: deploying contract ZKP, deploying contract VID, announcing public key, verifying ballot, achieving address list, achieving data list, returning VID, oracle operation, and receiving ZKP. Table 2 shows the above-mentioned functions’ gas fees.

Table 2. Gas Fee Performance.
Full size table

We observe in Table 2 that operations including announcing public key, achieving address list, and achieving data list are free of charge. The functions designed such that those are executed without revision by marking them with “view” in the definition statements of the functions when programming lead to this result. For this reason, plenty of gas fee is saved. The execution of verifying ballot consumes almost 0.007 Ether of gas fee, which is spent more than other operations. The utilizing of multiply iterations is the cause resulting in the excessive consumption of gas fee when executing the operation of verifying ballot.

Adding all gas fees in Table 2 yields the total cost of the operations under the condition of one voter’s participation equal to about 0.027 Ether. From another perspective, by employing qualitative modes of enquiry, we attempt to illuminate that the functions regarding contract deployment and data comparison take over a majority of expense of this system. The strategy on cost saving of the system can be established based on these functions.

6 Conclusion

In this paper, we proposed a smart contract-based e-voting system, which can satisfy most of the requirements, especially verifiability. Through the experiments on the execution-time performance and gas consumption, we showed the feasibility, efficiency, and scalability of our system, that can satisfy a majority of application scenarios including large-scale voting.

In future work, we consider the following aspects.

  • We have developed a system that combines multitudinous state-of-the-art techniques to make sure the data integrity and reliability, proving its performance based on qualitative evaluation. However, there is increasing concern that our system is not so stable as our evaluation because of the partial execution of centralized operations in the system. In particular, some of the voter’s privacy is possibly disclosed if the administrator has the malicious intention in these operations. According to these factors, we shall focus on how to establish a more decentralized system and to take smart contract as the replacement of the administrator in more functions.

  • Through the analysis of the execution-time performance and gas fee, we found that several functions can be modified for building a more cost-saving and efficient system. For this purpose, not only in python, but also in solidity, we shall apply some new strategies to the functions. In one case, as we mentioned, the operation of loading ZKP takes over 50% of the whole execution time, which affects the efficiency of the system. Therefore, our strategy for enhancing the execution time from this perspective is to change the oracle that has a better response performance. Consequently, designing and implementing these strategies are another core points in our future work.