Submitted:
27 December 2023
Posted:
29 December 2023
You are already at the latest version
Abstract
Keywords:
1. Introduction
- We propose a quantum-resistant Zero-Knowledge Data Authentication Scalable Transparent Argument of Knowledge (zk-DASTARK) scheme, which is designed to solve the challenging problem of preserving privacy and providing authentication of private data.
- Our proposed scheme is an extension of zk-STARK with a hash circuit. It will be used to generate a hash of the generated zero-knowledge proof, which is then used to generate a digital signature by a trusted data authenticator. Our proposed approach will assure the integrity and confidentiality of our data, without revealing any specifics about the input values.
- We propose a novel framework based on our proposed zk-DASTARK scheme. The proposed framework ensures the complete protection and confidentiality of user’s private data when interacting with DApps.
- We implemented our proposed framework on state-of-the-art quantum secure IOTA Blockchain [8]. To evaluate its feasibility and performance, we tested it on a smart contract running on the IOTA blockchain.
2. Background and Related work
2.1. Zero Knowledge Proof (ZKP)
- Completeness: The principle of completeness in a ZKP dictates that if both the prover and verifier adhere to the protocol’s guidelines there is a high probability that the verifier will accept the proof.
- Zero Knowledge: This property ensures that the verifying entity gains no additional information about the proving entity’s secret when executing the protocol.
- Soundness: The principle of soundness in a ZKP protocol ensures that the proving entity cannot deceive the verifying entity into accepting a false statement as true.
2.2. Blockchain
2.3. Smart Contract
2.4. CRYSTALS Dilithium
2.5. Decentralized Ledger
2.6. IOTA Blockchain
2.7. Zero-Knowledge Scalable Transparent Arguments of Knowledge (zk-STARK)
- Prove: This algorithm takes a private input , computes output and generates a proof encoding the polynomial computation.
- Verify: This algorithm takes the output and the proof as inputs and verifies them. If the verification is successful, it returns 1 otherwise 0.
- Scalability: zk-STARK is scalable due to its exponentially small proof verification time and nearly linear proof generation time.
- Zero Knowledge: zk-STARK constructs proof using a set of polynomials which hides the information about the statement being proven. The proof is then verified by the verifier, who can check for the correctness of the proof without needing any of the details of the statement itself.
- Transparency: zk-STARK does not require an initial trusted setup between the prover and verifier. Thus, unlike other proof systems, it is more transparent.
- Perfect Completeness: An honest prover having a valid proof generated through zk-STARK will always be able to persuade an honest verifier with a probability 1.
-
Knowledge Extractability: In zk-STARKs, the knowledge extractor is a probabilistic polynomial-time algorithm. that, given a valid proof and public input. It extracts the witness used to generate the proof. The security of zk-STARK relies on the hardness of finding a valid proof without the witness. Consequently the ability to extract the witness from a valid proof is an important property. The proof of knowledge extraction can be expressed formally defined as:Let P be a probabilistic polynomial-time (PPT) prover that generates a valid proof for an instance y with witness x. is a negligible function in n. Let V be a PPT verifier that takes input, the instance y and proof and outputs 1 if the proof is valid and 0 otherwise.Let E be a PPT knowledge extractor that takes as input the instance y and proof , and outputs x with probability p. Then for any adversary A that runs in time , there exists a simulator S that runs in time and outputs a pair that is indistinguishable from a pair generated by the prover P, such that
2.8. Related Work
3. Our Construction of zk-DASTARK
- Setup: This algorithm generates a public/private key pair using a post-quantum cryptographic algorithm named CRYSTALS Dilithium [7]. The generated keys will be later used by the DataAuth algorithm.
- DataAuth: To authenticate the proof, this algorithm takes the proof , and the metadata vector associated with input vector which was used to generate the proof , hashes them together using SHA-256 [32] and then using the private key generates a signature over the hash by using CRYSTALS Dilithium digital signature algorithm.
- Prove: This algorithm takes the vector obtained by performing the computation using zk-DASTARK circuit on private input vector . Performs the computation on it and generates a proof over it using zk-STARK and outputs a proof
- Verify: This algorithm takes the output vector , the proof , public key , hash h and signature . The algorithm first, verifies the signature. If the signature is valid, then it proceeds to verify the proof. If both the values are valid it outputs 1, otherwise, in case of invalid proof or signature, the output is 0.
- Prover: A prover is someone who wants to prove a statement to the verifier. The data authenticator generates a proof for the prover using the prove algorithm along with the private input vector provided by the prover, and tries to persuade the verifier that the proof and output is indeed generated from the input vector , by getting a digital signature of the data authenticator over the hash of the proof and the output .
- Data Authenticator: A data authenticator is a reliable trusted entity, responsible for authenticating the input vector by verifying the metadata associated with the input vector. After verification, the data authenticator uses the prove algorithm to generate proof by performing the computation using zk-DASTARK circuit on the input vector that is provided by the prover and then signs the proof with his secret key
- Verifier: A verifier is someone who wants to verify the claim being made by the prover. The verifier takes the proof , output , and signature and uses the verify algorithm to verify the claim. If the output obtained by the verify algorithm is 1 the claim is valid otherwise in case the output value is 0 the claim is invalid.
4. ZK-STARK in zk-DASTARK
| Algorithm 1 zk-STARK-Prover() |
|
| Algorithm 2 zk-STARK-Verifier() |
|
| Algorithm 3 zk-DASTARK-Prover() |
|
| Algorithm 4 zk-DASTARK-Verifier() |
|
5. STARKFeed: A Framework for authenticated data feed to DApp smart contract
- DApp: DApp are autonomous applications that operate on a blockchain. The most common examples of DApps are OpenSea, MakerDAO, Uniswap etc. DApps services are offered through a smart contract. Due to the decentralized nature of smart contracts, DApps are authority-free and cannot be controlled by a single entity.
- DApp-User: A DApp-user is a user who wishes to use the services being offered by the DApp. The user does not want to share his private information which is required to use the services being offered by the DApp due to data privacy concerns.
- Data Authenticator: A data authenticator is a trusted entity which is used to perform the computation, generate the proof and then authenticate it. The data authenticator is an external entity to the blockchain ecosystem. The data authenticator authenticates the proof by signing it with his private key . Anyone having the public key of the data authenticator can verify the signed proof .
- Blockchain Validators: All the transactions submitted, to be included in the blockchain need to be verified first. This task of verification of transactions is delegated to blockchain validators (miners). Validators execute complex consensus algorithms to verify and include transactions into blocks.
Scenario A: (Privacy Protected Authenticated Data Feed)
- Initialization: First of all, the data authenticator will execute the setup function. This is a one-time setup that is used, to generate his public/private key pair . The public/private key pair is used to authenticate the proof generated against DApp user’s private data.
- DataAuth: As per requirement to use the service offered by the DApp. The DApp user takes the private input , and metadata to Data Authenticator. First, it will use the zk-DASTARK circuit to compute output and hash h. Then, it executes zk-DASTARK.Prove to generate proof and in the end, it execute zk-DASTARK.DataAuth to produce a signature .
- Service Request: The DApp user after obtaining the signature , output and the proof , will send the DApp a request for service containing the proof , signature , output .
- Service Request Fulfillment: On receiving the service request, the blockchain validators execute the DApp to fulfill the request made by the DApp user. The validators first verify the request made, by executing zk-DASTARK.Verify if the verification is successful, then the DApp service logic will be executed with the output and the request will be fulfilled.
Scenario B (Privacy Protected Data Feed)
- Service Request: To avail of the service offered by the DApp. The DApp user will use the zk-DASTARK circuit to compute output . In this case, we do not need input data authentication. The DApp user can proceed directly to generate a zero-knowledge proof by executing zk-DASTARK.Prove, without authenticating input data by Data Authenticator. After obtaining the proof , the DApp user sends the Dapp a request for service containing the proof output .
- Service Request Fulfillment: On receiving the service request, the blockchain validators execute the DApp to fulfil the request made by the DApp user. Firstly, the validators will verify the request, by executing zk-DASTARK.Verify. If the verification is successful, then the DApp service logic will be executed with the output and the request will be fulfilled. An example of such a smart contract algorithm is mentioned in Figure 11
6. Discussion and Analysis
6.1. Security Analysis
6.2. Multiple Data Authenticators Support
6.3. Computation Cost Analysis
6.4. Comparison of our proposed framework with Well-known frameworks
7. Implementation and Performance Evaluation
- zk-DASTARK Module: The zk-DASTARK implements the four functions that include Setup, Prove, Verify, and DataAuth. The functionality of each of these functions has already been discussed in Section 3. This module also implements the zk-DASTARK computation calculation circuit.
- IOTA Blockchain: IOTA is a distributed ledger technology mainly designed for the Internet of Things (IoT) ecosystem but can also be used just like any other blockchain ecosystem [5]. It uses a directed acyclic graph (DAG) instead of a traditional blockchain to achieve scalability and low latency. IOTA’s DAG architecture allows parallel transaction processing to make it highly scalable. IOTA’s network consensus algorithm allows for fast confirmation times, making it suitable for real-time applications. IOTA blockchain offers many distinct features such as allowing users to do micro-transactions with a very minimal transaction fee, the data transfer feature provided by IOTA blockchain can be used to transfer data securely, masked messaging feature provided by IOTA blockchain can be used to broadcast encrypted and authenticated messages to subscribers.
- The DApp Smart Contract We implemented an example medical insurance DApp as an IOTA Smart Contract (ISC) running on webassembly (WASM) virtual machine (VM) in rust language [35]. The DApp user must be registered with DApp. To claim the insurance premium, the DApp user can use the proposed framework to prove his claim and the authenticity of his input data. The insurance premium is calculated from the output of following equation where are public parameters.
8. Conclusion
References
- Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system. Decentralized business review 2008, 21260. [Google Scholar]
- Daley, S. Blockchain Applications and Real-World Use Cases, 2023.
- coinbase. What is DeFi? https://www.coinbase.com/learn/crypto-basics/what-is-defi.
- Szabo, N. Smart contracts: building blocks for digital markets. EXTROPY: The Journal of Transhumanist Thought,(16) 1996, 18, 28. [Google Scholar]
- Buterin, V.; others. A next-generation smart contract and decentralized application platform. white paper 2014, 3, 2–1. [Google Scholar]
- Ben-Sasson, E.; Bentov, I.; Horesh, Y.; Riabzev, M. Scalable, transparent, and post-quantum secure computational integrity. Cryptology ePrint Archive 2018. [Google Scholar]
- Ducas, L.; Kiltz, E.; Lepoint, T.; Lyubashevsky, V.; Schwabe, P.; Seiler, G.; Stehlé, D. CRYSTALS-Dilithium: A lattice-based digital signature scheme. IACR Transactions on Cryptographic Hardware and Embedded Systems.
- Popov, S.; Lu, Q. IOTA: Feeless and free. IEEE Blockchain Technical Briefs 2019. [Google Scholar]
- Bernstein, D.J.; Lange, T. Post-quantum cryptography. Nature 2017, 549, 188–194. [Google Scholar] [CrossRef] [PubMed]
- Invocation - IOTA Learn, 2023.
- Validators - IOTA Learn, 2023.
- Parno, B.; Howell, J.; Gentry, C.; Raykova, M. Pinocchio: Nearly practical verifiable computation. Communications of the ACM 2016, 59, 103–112. [Google Scholar] [CrossRef]
- Kosba, A.; Miller, A.; Shi, E.; Wen, Z.; Papamanthou, C. Hawk: The blockchain model of cryptography and privacy-preserving smart contracts. 2016 IEEE symposium on security and privacy (SP). IEEE, 2016, pp. 839–858.
- Zhang, F.; Cecchetti, E.; Croman, K.; Juels, A.; Shi, E. Town crier: An authenticated data feed for smart contracts. Proceedings of the 2016 aCM sIGSAC conference on computer and communications security, 2016, pp. 270–282.
- Lipp, M.; Schwarz, M.; Gruss, D.; Prescher, T.; Haas, W.; Mangard, S.; Kocher, P.; Genkin, D.; Yarom, Y.; Hamburg, M. Meltdown. arXiv preprint arXiv:1801.01207, arXiv:1801.01207 2018.
- Kocher, P.; Horn, J.; Fogh, A.; Genkin, D.; Gruss, D.; Haas, W.; Hamburg, M.; Lipp, M.; Mangard, S.; Prescher, T.; others. Spectre attacks: Exploiting speculative execution. Communications of the ACM 2020, 63, 93–101. [Google Scholar] [CrossRef]
- Lu, Y.; Tang, Q.; Wang, G. Zebralancer: Private and anonymous crowdsourcing system atop open blockchain. 2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS). IEEE, 2018, pp. 853–865.
- Eberhardt, J.; Tai, S. Zokrates-scalable privacy-preserving off-chain computations. 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData). IEEE, 2018, pp. 1084–1091.
- Adler, J.; Berryhill, R.; Veneris, A.; Poulos, Z.; Veira, N.; Kastania, A. Astraea: A Decentralized Blockchain Oracle. 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), 2018, pp. 1145–1152. [CrossRef]
- van der Laan, B.; Ersoy, O.; Erkin, Z. Muscle: Authenticated external data retrieval from multiple sources for smart contracts. Proceedings of the 34th ACM/SIGAPP Symposium on Applied Computing, 2019, pp. 382–391.
- Johnson, D.; Menezes, A.; Vanstone, S. The elliptic curve digital signature algorithm (ECDSA). International journal of information security 2001, 1, 36–63. [Google Scholar] [CrossRef]
- Boneh, D.; Gentry, C.; Lynn, B.; Shacham, H. Aggregate and verifiably encrypted signatures from bilinear maps. Advances in Cryptology—EUROCRYPT 2003: International Conference on the Theory and Applications of Cryptographic Techniques, Warsaw, Poland, –8, 2003 Proceedings 22. Springer, 2003, pp. 416–432. 4 May.
- Saket, R.; Singh, N.; Dayama, P.; Pandit, V. Smart contract protocol for authenticity and compliance with anonymity on hyperledger fabric. 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC). IEEE, 2020, pp. 1–9.
- Park, J.; Kim, H.; Kim, G.; Ryou, J. Smart contract data feed framework for privacy-preserving oracle system on blockchain. Computers 2020, 10, 7. [Google Scholar] [CrossRef]
- Chen, L.; Yuan, R.; Xia, Y. Tora: A trusted blockchain oracle based on a decentralized tee network. 2021 IEEE International Conference on Joint Cloud Computing (JCC). IEEE, 2021, pp. 28–33.
- Gao, Z.; Zhuang, Z.; Lin, Y.; Rui, L.; Yang, Y.; Zhao, C.; Mo, Z. Select-Storage: A New Oracle Design Pattern on Blockchain. 2021 IEEE 20th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom). IEEE, 2021, pp. 1177–1184.
- Wan, Z.; Zhou, Y.; Ren, K. zk-AuthFeed: Protecting data feed to smart contracts with authenticated zero knowledge proof. IEEE Transactions on Dependable and Secure Computing 2022. [Google Scholar] [CrossRef]
- Lin, Y.; Du, H.; Niyato, D.; Nie, J.; Zhang, J.; Cheng, Y.; Yang, Z. Blockchain-Aided Secure Semantic Communication for AI-Generated Content in Metaverse. IEEE Open Journal of the Computer Society 2023, 4, 72–83. [Google Scholar] [CrossRef]
- Emami, A.; Keshavarz Kalhori, G.; Mirzakhani, S.; Akhaee, M.A. A blockchain-based privacy-preserving anti-collusion data auction mechanism with an off-chain approach. The Journal of Supercomputing.
- Bai, T.; Hu, Y.; He, J.; Fan, H.; An, Z. Health-zkIDM: A Healthcare Identity System Based on Fabric Blockchain and Zero-Knowledge Proof. Sensors 2022, 22. [Google Scholar] [CrossRef] [PubMed]
- Qiu, Z.; Xie, Z.; Jiang, X.; Ran, C.; Chen, K. Novel Blockchain and Zero-Knowledge Proof Technology-Driven Car Insurance. Electronics 2023, 12, 3869. [Google Scholar] [CrossRef]
- of Standards, N.I. ; Technology. Secure hash standard (SHS), 2015.
- Ben-Sasson, E.; Chiesa, A.; Spooner, N. Interactive oracle proofs. Theory of Cryptography: 14th International Conference, TCC 2016-B, Beijing, China, -November 3, 2016, Proceedings, Part II 14. Springer, 2016, pp. 31–60. 31 October.
- Arshad, R.; Riaz, Q. Quantum and Post-Quantum Cybersecurity Challenges and Finance Organizations Readiness. In Handbook of Research on Cybersecurity Issues and Challenges for Business and FinTech Applications; IGI Global, 2023; pp. 314–337.
- The Rust Programming Language. Accessed: 2023-09-12.
- Docker. What is a container? https://www.docker.com/resources/what-container/.















| Frameworks | Data Privacy | Data Authentication | Trusted third party setup | Quantum attack resistance |
|---|---|---|---|---|
| Kosba et al [13] | Yes | No | Yes | No |
| Zhang et al [14] | No | Yes | No | No |
| Lu et al [17] | Yes | Yes | Yes | No |
| Eberhardt et al [18] | Yes | No | Yes | No |
| Adler et al [19] | No | Yes | No | No |
| Bjorn et al [20] | No | Yes | No | No |
| Saket et al [23] | No | Yes | No | No |
| Junhoo et al [24] | Yes | No | Yes | No |
| Chen et al [25] | No | Yes | No | No |
| Zhipeng et al [26] | No | No | No | No |
| Zhiguo et al [27] | Yes | Yes | Yes | No |
| Yijing et al [28] | No | Yes | Yes | No |
| Emami et al [29] | Yes | Yes | Yes | No |
| Tianyu et al [30] | No | No | Yes | No |
| Qiu et al [31] | Yes | No | Yes | No |
| zk-DASTARK | Yes | Yes | Yes | Yes |
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |
© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).