# Decentralized Identity Authentication with Auditability and Privacy
## 5 Privacy-Preserving Protocol
### Final Protocol
#### 5.2.1 New Token and Its Consistency
## 7 Evaluation

### Performance Evaluation

We implemented our baseline and privacy-preserving protocols on Hyperledger Fabric. (We used an old version of Hyperledger Fabric, i.e., v0.6, instead of the newer versions because it had better security and performance.) This is a permissioned blockchain that uses PBFT consensus and supports Turing-complete smart contracts called _chaincodes_. It executes smart contracts inside Docker containers. Our implementation consisted of smart contract functions written in Golang, which provides rich support for complex data structures and cryptographic libraries. Signatures were implemented by using the _crypto/ecdsa_ library with the ed25519 curve. The _TokenVyf_ function in Algorithm 3, which contained the most complex logic for verification, was implemented by using _go-snark_[44]. The client and service provider were written in Golang. They interacted with the blockchain via REST APIs. The client used the _circom_ compiler [45] to compile the _Token_ circuit from Algorithm 3. To make the circuit more efficient, we used EdDSA with the Babyjub [46] elliptic curve to implement VRFs and MiMC7 [47] as the hash function. Computation integrity proofs were generated by using websnark ([[https://github.com/iden3/websnark](https://github.com/iden3/websnark)]([https://github.com/iden3/websnark](https://github.com/iden3/websnark)) (accessed on 18 October 2020). #### 7.1.1 Methodology

We evaluated the performance of our protocols by using the following metrics: (1) throughput: the number of authentication events completed per second; (2) latency: the end-to-end latency at the client; (3) cost breakdown: the computation cost at the client, service provider, and the blockchain node. We pre-generated the proofs and used up to 5 clients to generate increasing loads on the blockchain. Throughput was computed as the number of transactions included in the blockchain over the measurement period, which was set to 10 min. End-to-end latency was computed as the time from when the client submitted the transaction to when the transaction was included in the blockchain. We varied the size of the blockchain by varying its fault tolerance threshold \(f\). The number of nodes was \(3f+1\). We varied \(f\) from 0 to 6. This was to measure the impact of the consensus protocol on the overall performance. At \(f=0\), there was no consensus. At \(f>0\), the cost of the consensus increased with \(f\). Our experiments were run on both a local cluster and on AWS. Each cluster node had 8 GB of RAM, a 2.10 GHz CPU, and 1 Gbps Ethernet, and each was run on Ubuntu 18.04 OS. For AWS, we used t1.xlarge instances (4 vCPUs, 16 GB of RAM) across two regions (Singapore and Hong Kong). Unless stated otherwise, the results presented below are for a local cluster averaged over 5 runs. #### 7.1.2 Results

We first measured the throughput by varying client request rates. The results for \(f=4\) (or 13 nodes) are shown in Figure 2 (the results for other values of \(f\) are similar). The throughput of the baseline protocol increased to 380 authentication events per second, whereas that of the privacy-preserving protocol peaked at 0.35 authentication events per second (or roughly one authentication for every 3 s). The low throughput of the latter was due to the overhead of the zkSNARK primitives. Each proof was only 784 bytes, but verifying it took 3.18 s on average. The baseline performance was lower than but consistent with the results in [11] because of the overhead in signature verification. Figure 3 shows the peak throughputs for varying \(f\) and the latencies at these throughputs. It can be seen that increasing the number of blockchain nodes did not effect the privacy-preserving protocol. In particular, the throughput remained at 0.35 authentication events per second. In contrast, the baseline protocol suffered a drop of 30% from 380 to 280 events per second. Furthermore, the latency remained constant with increasing \(f\), with 3 s on average for the baseline and 30 s on average for the privacy-preserving protocol.