# A Data Sharing Scheme for GDPR-Compliance Based on Consortium Blockchain
## 5 Analysis and Discussion
### Performance Evaluation  
In this paper, we propose a blockchain-based scheme, we implemented the prototype of the proposed scheme based on python. Transaction records between users and service providers are stored in blocks. The zk-SNARK algorithm is implemented by the PySNARK library. The experiments were performed in the following environment: (i) Intel Core i7-10700K CPU (3.8 GHz); (ii) 256 GB RAM; (iii) Ubuntu Linux 20.04.1 Server (64-bit); and (iv) Python 3.7.0. Initially, we conducted a comparative experiment on the block generation time between the proposed scheme and others. Figure 8 represents the experimental result of our scheme compared with the existing works, our solution has the best performance among the three schemes. In the experiment,  
performance is affected by the consensus mechanism. The study [15] applies Proof of Work (PoW) in their system, nodes obtain the right to create a new block through competition and mining. PoW requires high computing resources and equipment. The Practical Byzantine Fault Tolerance (PBFT) algorithm is used in [17], which is suitable for permitted systems, but its communication complexity is relatively high. The authors in [19] use the Proof of Stack (PoS) as their consensus mechanism. PoS is hosted by the node with the most tokens, and uses a random process to determine which node will generate the next block. The CEM-PoA consensus proposed in our scheme is designed for consortium blockchain, it does not require nodes to spend computing resources to solve complex mathematical tasks, but relies on reliable nodes with a high reputation to generate blocks. It can be seen from the result in Figure 8 that the growth rate of the proposed scheme is more stable and faster, which has a 41% block generation growth rate. Therefore, compared with PoW, PBFT, and PoS, the proposed CEM-PoA is highly efficient. Additionally, the efficiency of the consortium blockchain is higher than the public blockchain in most instances. In addition to the block generation time of the scheme, we also focus on the time consume related to zk-SNARK. We simulated nine phases of the proposed scheme in the same environment, and mainly evaluated the time to generate ZK-proof key pairs, ZK-proof generation, and verification time under different inputs. Each experiment was repeated 200 times and their average value was calculated. The challenge of the proposed scheme is ZK-proof's time consumption. We set the security parameter \(\lambda\) with a security level of 128 bits. The number of inputs is set to 200, 400, 600, 800, and 1000, respectively. The following findings show the efficiency and feasibility of our zk-SNARK algorithm. Figure 9 illustrates the generation time of a ZK-proof key pair under different inputs. It shows that the time to generate a ZK-proof key pair \((EK_{c},VK_{c})\) is about 16.5 s. Regardless of the number of inputs, the generation time is almost constant. Even the number of circuit inputs is 1000, the difference almost remains within milliseconds, which is an acceptable time constraint for overall performance. The ZK-proof key pair generation only needs to be executed once, so the related costs are not a problem for the whole blockchain. Figure 10 illustrates the generation time of ZK-proofs under different inputs. The proof generation is only run by a part of the nodes, not the whole blockchain system. Therefore, it will not significantly affect the overall performance of the system. The generation proof time only fluctuates slightly and has no apparent relationship with the number of inputs, the experimental results remain within acceptable limits. Figure 8: Comparison of block generation time. We provide the experiment results of ZK-proof verification in Figure 11. The ZK-proof verification is run by every smart contract in the blockchain, and it can be found that the time of verification increases linearly as the input increases, but the whole is less than 1 s. The time fluctuation is within milliseconds, and thus the result still can be considered feasible.