Preprint
Article

This version is not peer-reviewed.

Working Capital Management Strategies and Financial Performance: A Cause-and-Effect Analysis

A peer-reviewed version of this preprint was published in:
Journal of Management Research and Analysis 2024, 11(1), 3-11. https://doi.org/10.18231/j.jmra.2024.002

Submitted:

27 December 2023

Posted:

29 December 2023

You are already at the latest version

Abstract
This study examines the effects of working capital management strategies on firm’s financial performance of Indian cement companies using 11-year (2010-2020) financial data of 31 companies listed in Bombay Stock Exchange. It is intended to find out whether the strategies made by finance managers with respect to the components of working capital such as average receivable period, inventory conversion period, average payment period and cash conversion cycle, etc. affects the firm’s performances individually and in total. The results of Pearson’s correlation coefficient and random effect regression model shows that there exists a negative relationship between financial performance measured in terms of return on assets (ROA) and inventory turnover period (ITP) as well as accounts payable period (APP), whereas firm’s performance is not significantly affected by accounts receivable period (ARP) and cash conversion cycle (CCC). Similarly, it has been observed that the liquidity measures such as current ratio (CR) and quick ratio (QR) have a significant positive association with ROA. Moreover, the size of the firms and leverage are inversely related to ROA but the age of the firms is not significantly affecting their financial performances. Hence, it can be concluded that how an organisation designs its working capital strategy do have an impact on its performances.
Keywords: 
;  ;  ;  ;  

1. Introduction

Blockchain is a decentralized immutable digital ledger used for recording transactions permanently across a peer-to-peer(P2P) network of computers. Blockchain offers a number of distinct features such as immutability, transparency, robust security and fault tolerance. The security of blockchain depends on a decentralized network of validators which follows a consensus algorithm to validate any transactions. The decentralization feature of blockchain enables transparency, integrity and trust among participants. Since its inception, from simply being implemented as a peer-to-peer cryptocurrency such as Bitcoin [1] with limited features and capabilities, blockchain has evolved rapidly over the years. New protocols, consensus algorithms and use cases such as smart contracts, and Decentralized Finance (DeFi) have been proposed in literature. [2] [3].
Nick Szabo [4] proposed the idea of smart contracts, to automate and digitize manual contracts. In blockchain scenario, a smart contract can be taken as a digital contract executing on the blockchain and its execution is validated via consensus mechanism. Ethereum [5] being turing complete enables smart contracts to execute any complex logic. The coupling of smart contracts with blockchain offers attractive features, which has enabled rapid adoption and application of blockchain in various application areas such as, smart grids, health care, supply chain, finance, IoT etc.
When real-world applications such as supply chain management, identity management, banking and finance etc. are built utilizing smart contracts and blockchain, real-world data from external sources such as input from users or an API etc. are needed to be fed into the smart contract as input values. There are two issues related to input data. The first one is related to the authentication of the data and the second one is related to the privacy of the data because in some use cases such as medical records input data cannot be public to everyone. In such scenarios to execute smart contract the authenticity of data being fed into smart contract needs to be verified by the blockchain validators. This gives rise to a challenging problem, i.e., the blockchain validators should not only be able to verify the authenticity of the available plain text input data but also maintain the privacy of that input data.
The traditional data feed schemes for smart contracts do not ensure privacy and authentication of data moreover these schemes require an initial trusted setup and are vulnerable to quantum threats, risking both the privacy and integrity of data. Our solution leverages the strengths of quantum secure zk-STARK, CRYSTALS Dilithium, and the IOTA blockchain. zk-STARK provides a framework for zero-knowledge proofs, preserving data privacy without a trusted setup. CRYSTALS Dilithium offer a quantum-resistant mechanism for digital signatures, ensuring data integrity. The IOTA blockchain, with its unique Tangle technology, provides a scalable platform for implementing these technologies in smart contracts. This combination presents a quantum-safe data feed scheme that not only maintains privacy but also verifies data authenticity. It’s a significant stride towards securing digital transactions against quantum threats, fostering trust in the system.
The main contribution of our work is as follows:
  • 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 the extension of quantum secure zk-STARK [6] with a post-quantum digital signature scheme named the CRYSTALS Dilithium  [7].
  • 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.

3. Our Construction of zk-DASTARK

In this section, we discuss the construction of our proposed system zk-DASTARK. Our proposed construction is designed to solve the challenging problem of privacy preservation and private data authentication. Our proposed system comprises a circuit called the zk-DASTARK circuit which consists of a computation circuit and a hash circuit as shown in Figure 3
The computation circuit takes private input x and public input p to compute y . The hash circuit takes the generated zero-knowledge proof π and metadata m that is associated with private input to generate a hash which will be signed by a data authenticator for authentication.
In addition, zk-DASTARK has four polynomial time algorithms that include Setup, DataAuth, Prove and Verify. The functionality of each algorithm is described as follows:
  • Setup ( s k a , p k a ) : This algorithm generates a public/private key pair ( s k a , p k a ) using a post-quantum cryptographic algorithm named CRYSTALS Dilithium [7]. The generated keys will be later used by the DataAuth algorithm.
  • DataAuth ( π , m , s k a ) σ a : To authenticate the proof, this algorithm takes the proof π , and the metadata vector m associated with input vector x which was used to generate the proof π , hashes them together using SHA-256 [32] and then using the private key s k a generates a signature σ a over the hash by using CRYSTALS Dilithium digital signature algorithm.
  • Prove ( x , y ) π : This algorithm takes the vector y obtained by performing the computation using zk-DASTARK circuit on private input vector x . Performs the computation on it and generates a proof π over it using zk-STARK and outputs a proof π
  • Verify ( y , π , p k a , σ a ) 0 , 1 : This algorithm takes the output vector y , the proof π , public key p k a , hash h and signature σ a . 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.
In zk-DASTARK, there are three entities which are Prover, Data Authenticator and Verifier, that interact with the proposed system. The prover, Data Authenticator and verifier are described as follows:
  • 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 x provided by the prover, and tries to persuade the verifier that the proof π and output y is indeed generated from the input vector x , by getting a digital signature of the data authenticator over the hash of the proof π and the output y .
  • Data Authenticator: A data authenticator is a reliable trusted entity, responsible for authenticating the input vector x 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 x that is provided by the prover and then signs the proof π with his secret key σ a
  • Verifier: A verifier is someone who wants to verify the claim being made by the prover. The verifier takes the proof π , output y , and signature σ a 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.
Example: To demonstrate how zk-DASTARK can be utilized to feed authenticated inputs to DApps without compromising privacy, we can take a simple example of a medical insurance DApp. The DApp takes values of blood pressure, sugar level, age and pulse rate that are stored in the variables x 1 , x 2 , x 3 , x 4 respectively. The insurance company has defined a simple polynomial function
y = f ( x 1 , x 2 , x 3 , x 4 ) = 3 x 1 + 7 x 2 + 11 x 3 + 13 x 4
The insurance amount is determined based on output. Variables x 1 , x 2 , x 3 , x 4 are sensitive values of the user which he wants to protect from being exposed whereas the coefficients are known public parameters. zk-STARK can be utilized to encode the polynomial computation in a proof π to show that output y was calculated from x 1 , x 2 , x 3 , x 4 without disclosing them. However, zk-STARK does not offer data authenticity to the user, hence the data may comprise fake/forged values. To prevent this scenario, a hash circuit is used additionally with zk-STARK. This hash circuit takes the proof π hashes it and generates a hash value. The hash value generated is then signed by a reliable trusted data authenticator to ensure the authenticity of the input data. This ensures that before the proof verification, one can verify whether the signature is valid or not. If it is valid, then one can proceed to verify the proof π , which guarantees that y was indeed computed from the correct inputs.

4. ZK-STARK in zk-DASTARK

In this section, we describe how zk-DASTARK integrates zk-STARK to feed authenticated inputs to DApps without compromising privacy. With an interactive zero-knowledge proof system, the correctness of complex statements can be proven interactively. This was formally introduced in  [33] as Interactive Oracle Proof (IOP). In IOP, instead of verifying the entire proof, the verifier queries on some part of the proof selected uniformly at random.
The proof system zk-SNARK  [6] belongs to this IOP family. In zk-STARK, the proof system works on an algebraic representation of computation, where there is a chain of internal states A 1 , A 2 , , A m and several polynomial relations ( p i ’s) among those: p i ( A i 1 , A i 2 , , A i m ) = 0 . It is then asserted that the computation is correct if and only if it satisfies the relations.
As explained in Example 1, a medical insurance DApp takes values of blood pressure, sugar level, age and pulse rate represented as x i ’s. The insurance company has defined a simple polynomial function
y = f ( x 1 , x 2 , , x n ) = a i x i .
The insurance company wants to convince the party that y has been computed on correct x i ’s as input. In the context of zk-STARK as a verifiable computation, we can define the language L as a set of pairs ( X , X ) such that C ( X ) = X for deterministic computation C. Then one can assert that X is the result of C applied to X by proving that ( X , X ) L . In the context of medical insurance DApp, the party wants to compute C ( X ) = A . X which outputs y where X = ( x 1 , x 2 , , x n ) and A = ( a 1 , a 2 , , a n ) . The insurance company returns y and the proof π as the output of P r o v e ( X , y ) . Here we describe this algorithm. Before that, we provide some tools which are essential for this algorithm.
Let F ( x , N ) be a function which on input x and N, computes x N as follows: x 0 = x and x i = x i 1 2 for i = 1 N . Consider the function f ( i ) = x i for i = 0 , 1 , , p . This function can be constructed by interpolation. Let us consider the constraint c ( A , B ) = B 2 A . Thus C f ( i + 1 ) , f ( i ) = 0 for all i { 1 , , N } . It can be noted that the polynomial C ( f ( x + 1 ) , f ( x ) ) is of degree 2 N and has roots 0 , 1 , 2 , , N . So the polynomial D ( x ) = x ( x 1 ) ( x p ) divides C. Define g ( x ) = C ( f ( x + 1 ) , f ( x ) ) D ( x ) . It may be noted that if the prover computes all the steps correctly then for all s R Z N , g ( s ) is C ( f ( s + 1 ) , f ( s ) ) D ( s ) . Using these steps, we first describe zk-STARK-Prover() and zk-STARK-Verifier() which are basic building blocks for zk-DASTARK-Prover() and zk-DASTARK-Verifier().
Algorithm 1 zk-STARK-Prover()
Input: 
N, s, x
Output: 
x N , π x
1:
set i = 1; and S = ϕ;
2:
while in do
3:
set i = 1 ; and S = ϕ ;
4:
while i n do
5:
   compute x i = x i 1 2 ;
6:
   set f ( i ) = x i ;
7:
    S = S { ( i , f ( i ) } ;
8:
end while
9:
interpolate to construct f ( ) from datapoints in S ;
10:
construct D ( x ) = j = 0 N ( x j ) ;
11:
Construct g ( x ) = C f ( x + 1 ) , f ( x ) D ( x ) ;
12:
compute f ( s ) , f ( s + 1 ) , g ( s ) ;
13:
π = f ( s ) , f ( s + 1 ) , g ( s ) ;
14:
output x N | | π x ;
Algorithm 2 zk-STARK-Verifier()
Input: 
π x
Output: 
b _ r e t _ v a l
1:
set b _ r e t _ v a l = false ;
2:
parse
3:
set b _ r e t _ v a l = f a l s e ;
4:
parse π = f ( s ) , f ( s + 1 ) , g ( s ) ;
5:
if g ( s ) = = C ( f ( s + 1 ) , f ( s ) ) D ( s ) then
6:
   set b _ r e t _ v a l = t r u e ;
7:
end if
8:
return b _ r e t _ v a l ;
In the interactive proof system, the verifier inputs a number N and a random number s R Z N * . In the following lemma we study an important property which is crucial for the final proof of zk-DASTARK-Prover() (see Remark ). Let y = i = 1 n a i x i . Also let Y j + 1 = Y j 2 , where Y 0 = y . Similarly let V i , 0 = a i x i and V i , j + 1 = V i , j 2 for all i { 1 , , n } . Then, in Z 2 N , Y N = V i , N .
Proof. 
It may be noted that, Y N = y 2 N and V j , N = V j , 0 2 N for all i { 0 , , n } . Also in Z 2 N , y 2 N = j = 1 n a j x j 2 N = j = 1 n a j x j 2 N = j = 1 n V j , 0 2 N = j = 1 n V j , N    □
Algorithm 3 zk-DASTARK-Prover()
Input: 
p, s, X = ( x 1 , , x n ) , A = ( a 1 , , a n )
Output: 
y, π
1:
compute
2:
compute y = A . X mod p;
3:
compute ( Y N , π y ) = zk-STARK-Prover( N , s , y );
4:
while i n do
5:
   compute ( V i , N , π x i ) = zk-STARK-Prover( N , s , x i );
6:
end while
7:
compute π = π y | | π x 1 | | | | π x n ;
8:
output ( y | | Y N | | V 1 , N | | | | V n , N | | π ) ;
Algorithm 4 zk-DASTARK-Verifier()
Input: 
π
Output: 
b _ r e t _ v a l
1:
set b _ r e t _ v a l 0 = f a l s e ;
2:
parse π as ( y | | Y N | | V 1 , N | | | | V n , N | | π y | | π x 1 | | | | π x n ) ;
3:
if Y N m o d 2 N = = ( j = 1 n V j , N ) m o d 2 N then
4:
   set b _ r e t _ v a l 0 = t r u e ;
5:
end if
6:
while i n do
7:
    b _ r e t _ v a l i = zk-STARK-Verifier( π x i );
8:
end while
9:
b _ r e t _ v a l = i = 0 n b _ r e t _ v a l i ;
10:
return b _ r e t _ v a l ;
It may be noted that Lemma 4 forms the ground of the proof of correctness of zk-DASTARK-Verifier() algorithm. The left hand side of line 3 of zk-DASTARK-Verifier() is Y N and the right hand side is j = 1 n V j , N in Z 2 N . Thus, clearly from Lemma 4, the correctness of zk-DASTARK-Verifier() is asserted.
From line 4 of zk-DASTARK-Prover(), the number of calls to the zk-STARK-Prover() is only as much as the number of variables n in the polynomial defined by the insurance company in Example 1 which is linear in the complexity of zk-STARK-Prover() algorithm. Similarly, from line 7 of zk-DASTARK-Verifier(), the complexity is liner in n.

5. STARKFeed: A Framework for authenticated data feed to DApp smart contract

In this section, we propose a novel framework based on zk-DASTARK, which can be used for authenticated data feed to DApps without compromising data privacy. Figure 4, Figure 5, Figure 6, Figure 7, Figure 8 and Figure 9 describes the architecture and working of the zk-DASTARK framework.
The framework consists of four participants: Decentralized Application (DApp), DApp-User, Data Authenticator and Blockchain validators.
  • 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 s k a . Anyone having the public key p k a 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.
We take two scenarios to describe how our proposed framework works and how it leverages zk-DASTARK. In Scenario A, privacy and authentication of private input data are required. In Scenario B, only the privacy of private input data is required without the need for input authentication.

Scenario A: (Privacy Protected Authenticated Data Feed)

In this scenario, both privacy and authentication of private input data are required. The working mechanism of the proposed framework is explained in the following steps:
  • 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 ( s k a , p k a ) . 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 x , and metadata m to Data Authenticator. First, it will use the zk-DASTARK circuit to compute output y and hash h. Then, it executes zk-DASTARK.Prove ( x , y ) to generate proof π and in the end, it execute zk-DASTARK.DataAuth ( π , m , s k a ) to produce a signature σ a .
  • Service Request: The DApp user after obtaining the signature σ a , output y and the proof π , will send the DApp a request for service containing the proof π , signature σ a , output y .
  • 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 ( y , π , p k a , σ a ) if the verification is successful, then the DApp service logic will be executed with the output y and the request will be fulfilled.
The proposed framework execution protocol along with smart contract is given in Figure 10

Scenario B (Privacy Protected Data Feed)

In this scenario, the privacy of private input data is required without the need for input authentication. The detailed working of the proposed framework is explained in the following steps:
  • Service Request: To avail of the service offered by the DApp. The DApp user will use the zk-DASTARK circuit to compute output y . 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 ( x , y ) , 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 y .
  • 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 ( y , π , n u l l , n u l l ) . If the verification is successful, then the DApp service logic will be executed with the output y and the request will be fulfilled. An example of such a smart contract algorithm is mentioned in Figure 11

6. Discussion and Analysis

In this section, we discuss the design considerations for our zk-DASTARK scheme and then compare it with existing well-known schemes.

6.1. Security Analysis

The authenticity of data in our proposed framework is ensured through a specially designed circuit in the zk-DASTARK scheme. The Data authenticator endorses the authenticity of the DApp user’s private input data, by first computing the output y . It then generates proof π and then computes a hash value h = H ( π , m ) using SHA-256 as the hash function and signs the computed hash value with its private key s k a using a quantum-resistant digital signature scheme CRYSTALS Dilithium2 [7]. The security of CRYSTALS Dilithium2 is based on the hardness of Fiat Shamir with Aborts, Ring Short Integer Solution (SIS) and Learning with Errors (LWE) modules. Due to the collision resistance property offered by the hash function, it is impossible to find another user’s private input and metadata such that h = H ( π , m ) . Additionally, zk-DASTARK guarantees computational zero-knowledge property, which ensures that y is computed from x and p without disclosing x , also zk-STARK offers resistance against quantum attacks.
To prove the knowledge extractability of our scheme zk-DASTARK, let’s assume there is a probabilistic polynomial-time adversary A and knowledge extractor E which can break the knowledge extraction of zk-DASTARK. There also exist S e t u p ^ and P r o v e ^ simulator algorithms for the adversary. The probability for extracting witness x is non-negligible, the formal proof is given below:
1 . S e t u p ^ s k a , p k a 2 . A P r o v e ^ ( . ) , D a t a A u t h ( s k a , . ) ^ ( π , p , y , σ a ) 3 . P r E ( O u t p u t L i s t A ) x n e g l ( n )
where O u t p u t L i s t A is the list of inputs and outputs generated by adversary A, n e g l ( n ) is a negligible function in n.

6.2. Multiple Data Authenticators Support

Our proposed framework currently supports one data authenticator but it can be extended to use cases where input data need to be authenticated from multiple data authenticators or different sets of inputs require authentication from different data authenticators. Our proposed framework has the flexibility to be extended to multiple data authenticators as shown in Figure 12.

6.3. Computation Cost Analysis

The computation cost of zk-DASTARK depends on several factors that include the complexity of the arithmetic circuit being verified, the degree of the polynomial used to generate the zk-STARK zero knowledge proof, and the desired level of security. The computation time and storage space required in our proposed scheme depends upon the provided number of inputs. The increase in the number of inputs increases the time and storage space required to generate zero knowledge proof The same phenomenon goes for the digital signature generation. But on the other hand, if we compare proof generation time and proof verification time, the proof verification time is significantly less than the proof generation time. It proves that the zk-STARK verifier works in much faster way in verifying zero knowledge proofs.

6.4. Comparison of our proposed framework with Well-known frameworks

A comparison of our proposed zk-DASTARK framework against well-known frameworks in terms of data privacy, data authentications, trusted third party setup and quantum attack resistance given in Table 1. It shows that our proposed framework offers better data privacy and authentication and it does not require any trusted third party setup. A salient feature of our proposed framework quantum attacks resistance [34].

7. Implementation and Performance Evaluation

The implementation and performance evaluation of our proposed framework was conducted on a Personal Computer (PC) with following specifications: Processor Intel Core i5-8250U@1.60GHz*8 and 24GB RAM, running 64bit Ubuntu 22.04. Our implementation consists of the following three components:
  • 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 y = f ( x ) = c 1 x 1 + c 2 x 2 + c 3 x 3 + . . . . + c n x n where c 1 , c 2 . . . c n are public parameters.
The blockchain network was constructed of five IOTA Wasp nodes and five Hornet nodes running inside docker containers [36]. Figure 13 shows the time taken in milliseconds (ms) to generate zero-knowledge proof against the given number of inputs. As the number of inputs increases, the time taken to generate the zero-knowledge proof also increases. It shows that number of inputs is linearly proportional to zero-knowledge proof generation time. Figure 13 shows a similar increasing trend in computational time (milliseconds or ms) taken to generate the digital signature by the Data Authenticator against the given number of inputs. Similarly, Figure 13 depicts the time taken in ms to verify zero-knowledge proof against the given number of inputs. As the number of inputs increases, the time taken to verify the zero-knowledge proof also increases.
Figure 14 depicts the increasing relationship trend between the number of inputs and zero-knowledge proof size (computed in bytes). Figure shows the relationship between the number of inputs and gas units consumed by DApp during zero-knowledge proof verification. An increase in gas consumption can be seen as the number of inputs increases.
Figure 15, Figure 15 depicts a comparison between zk-DASTARK and zk-AuthFeed [27]. Figure 15 shows that zk-Authfeed is much faster than zk-DASTARK in Zero Knowledge Proof generation whereas Figure 15 shows that zk-DASTARK is much faster in verifying Zero Knowledge Proof than zk-Authfeed.

8. Conclusion

The emergence of blockchain and smart contracts evolves traditional digital applications such as identity management, supply chain management, banking and finance etc. into DApps. The DApps running on the blockchain using smart contracts require access to authentic off-chain data but the users are more conscious of the privacy of their data and consequently are more reluctant to share their data. This poses a significant challenge in the adoption of DApps worldwide. In this work, we introduce the zk-DASTARK, a quantum attack-resistant framework that provides both privacy and authenticity for off-chain private data input to smart contracts on the blockchain. Our framework is built upon an extended zk-STARK with a hash circuit and a post-quantum digital signature scheme. Our proposed framework eliminates the need for the establishment of a trusted setup, as required by other well-known zero-knowledge schemes. Our proposed framework is quite efficient in performance as compared with well-known off-chain data authentication frameworks.

References

  1. Nakamoto, S. Bitcoin: A peer-to-peer electronic cash system. Decentralized business review 2008, 21260. [Google Scholar]
  2. Daley, S. Blockchain Applications and Real-World Use Cases, 2023.
  3. coinbase. What is DeFi? https://www.coinbase.com/learn/crypto-basics/what-is-defi.
  4. Szabo, N. Smart contracts: building blocks for digital markets. EXTROPY: The Journal of Transhumanist Thought,(16) 1996, 18, 28. [Google Scholar]
  5. Buterin, V.; others. A next-generation smart contract and decentralized application platform. white paper 2014, 3, 2–1. [Google Scholar]
  6. Ben-Sasson, E.; Bentov, I.; Horesh, Y.; Riabzev, M. Scalable, transparent, and post-quantum secure computational integrity. Cryptology ePrint Archive 2018. [Google Scholar]
  7. 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.
  8. Popov, S.; Lu, Q. IOTA: Feeless and free. IEEE Blockchain Technical Briefs 2019. [Google Scholar]
  9. Bernstein, D.J.; Lange, T. Post-quantum cryptography. Nature 2017, 549, 188–194. [Google Scholar] [CrossRef] [PubMed]
  10. Invocation - IOTA Learn, 2023.
  11. Validators - IOTA Learn, 2023.
  12. Parno, B.; Howell, J.; Gentry, C.; Raykova, M. Pinocchio: Nearly practical verifiable computation. Communications of the ACM 2016, 59, 103–112. [Google Scholar] [CrossRef]
  13. 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.
  14. 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.
  15. 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.
  16. 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]
  17. 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.
  18. 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.
  19. 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]
  20. 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.
  21. 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]
  22. 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.
  23. 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.
  24. 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]
  25. 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.
  26. 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.
  27. 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]
  28. 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]
  29. 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.
  30. 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]
  31. 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]
  32. of Standards, N.I. ; Technology. Secure hash standard (SHS), 2015.
  33. 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.
  34. 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.
  35. The Rust Programming Language. Accessed: 2023-09-12.
  36. Docker. What is a container? https://www.docker.com/resources/what-container/.
Figure 1. Blockchain flow diagram
Figure 1. Blockchain flow diagram
Preprints 93731 g001
Figure 2. Smart contract flow diagram
Figure 2. Smart contract flow diagram
Preprints 93731 g002
Figure 3. An extended computation circuit for zk-DASTARK with an additional hash circuit.
Figure 3. An extended computation circuit for zk-DASTARK with an additional hash circuit.
Preprints 93731 g003
Figure 4. STARKFeed - Setup
Figure 4. STARKFeed - Setup
Preprints 93731 g004
Figure 5. STARKFeed - Sharing data with data authenticator
Figure 5. STARKFeed - Sharing data with data authenticator
Preprints 93731 g005
Figure 6. STARKFeed - Getting proof and authenticated data back
Figure 6. STARKFeed - Getting proof and authenticated data back
Preprints 93731 g006
Figure 7. STARKFeed - Requesting service
Figure 7. STARKFeed - Requesting service
Preprints 93731 g007
Figure 8. STARKFeed - Sending the proof to DApp
Figure 8. STARKFeed - Sending the proof to DApp
Preprints 93731 g008
Figure 9. STARKFeed - Request fulfilled
Figure 9. STARKFeed - Request fulfilled
Preprints 93731 g009
Figure 10. Framework execution protocol and smart contract with data authentication
Figure 10. Framework execution protocol and smart contract with data authentication
Preprints 93731 g010
Figure 11. Framework execution protocol and smart contract without data authentication
Figure 11. Framework execution protocol and smart contract without data authentication
Preprints 93731 g011
Figure 12. zk-DASTARK with multiple data authenticators
Figure 12. zk-DASTARK with multiple data authenticators
Preprints 93731 g012
Figure 13. Computational latency (in ms) as the number of inputs increase to the Zero Knowledge Proof Generation (a), Digital Signature Generation (b) and the Zero Knowledge Proof Verification (c)
Figure 13. Computational latency (in ms) as the number of inputs increase to the Zero Knowledge Proof Generation (a), Digital Signature Generation (b) and the Zero Knowledge Proof Verification (c)
Preprints 93731 g013
Figure 14. Size vs. Number of Inputs for Zero Knowledge Proof Generation
Figure 14. Size vs. Number of Inputs for Zero Knowledge Proof Generation
Preprints 93731 g014
Figure 15. Computational latency (in ms) comparison for Zero Knowledge Proof generation between zk-Authfeed and zk-DASTARK (a), Computational latency (in ms) comparison for Zero Knowledge Proof verification between zk-Authfeed and zk-DASTARK (b)
Figure 15. Computational latency (in ms) comparison for Zero Knowledge Proof generation between zk-Authfeed and zk-DASTARK (a), Computational latency (in ms) comparison for Zero Knowledge Proof verification between zk-Authfeed and zk-DASTARK (b)
Preprints 93731 g015
Table 1. Comparison of zk-DASTARK framework with well-known frameworks
Table 1. Comparison of zk-DASTARK framework with well-known frameworks
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.
Copyright: This open access article is published under a Creative Commons CC BY 4.0 license, which permit the free download, distribution, and reuse, provided that the author and preprint are cited in any reuse.
Prerpints.org logo

Preprints.org is a free preprint server supported by MDPI in Basel, Switzerland.

Subscribe

Disclaimer

Terms of Use

Privacy Policy

Privacy Settings

© 2026 MDPI (Basel, Switzerland) unless otherwise stated