Zero Knowledge Proof Solutions to Linkability Problems in Blockchain-Based Collaboration Systems

Abstract

Blockchain provides the opportunity for organizations to execute trustable collaborations through smart contract automations. However, linkability problems exist in blockchain-based collaboration platforms due to privacy leakages, which, when exploited, will result in tracing transaction patterns to users and exposing collaborating organizations and parties. Some privacy-preserving mechanisms have been adopted to reduce linkability problems through the integration of access control systems to smart contracts, off-chain data storage, usage of permissioned blockchain, etc. Still, linkability problems persist in applications deployed in both private and public blockchain networks. Zero-knowledge proof (ZKP) systems provide mechanisms for verifying the correctness of transactions and actions executed on the blockchain without revealing complete information about the transaction. Hence, ZKP systems provide a potential solution to eliminating linkability problems in blockchain-based collaboration systems. The objective of this paper is to identify various linkability problems that exist in blockchain-enabled collaboration systems and understand how ZKP algorithms and smart contract frameworks can be used in addressing the linkability problems. Furthermore, a proof of concept (PoC) is implemented and simulated to demonstrate a ZKP system for a privacy-preserving feedback mechanism that mitigates linkability problems in collaboration systems. The scenario-based results from the PoC evaluation show that a feedback system that includes project participants’ verification through membership proofs, verification of on-time submission of feedback through range proofs, and encrypted calculation of feedback scores through homomorphic arithmetic provides a privacy-aware system for executing collaborations on the blockchain without linking project participants.

1. Introduction

Blockchain provides the opportunity for executing trustable inter-organizational collaborations through smart contracts for automated execution of collaboration logic, manipulation-resistant ledgers for storing outcomes of collaboration, and decentralized governance mechanisms for managing collaboration processes [1,2,3]. However, privacy issues have limited the adoption of blockchain technology stacks in business and organizational use cases [4]. Several privacy-preserving mechanisms have been developed and applied to address privacy leakage issues in blockchain-based collaboration systems such as the usage of permission blockchains [5,6], off-chain storage of sensitive data [7,8], access control mechanisms [9,10], etc.

The linkability problem is one example of privacy issues that have persisted in blockchain-based collaboration systems. Linkability is defined as the problem of associating transactions on a blockchain or action executions from a smart contract to a particular entity, such as a user or an organization [11]. This raises serious security concerns since third parties and malicious actors can infer sensitive information about an entity, such as financial behavior, business relationships, and social connections, by linking their transactions on blockchain. One instance of a linkability problem on its own may not reveal confidential information about a user’s identity; however, combining various types of linkability problems will result in more serious privacy implications. Exploiting linkability vulnerability in blockchain-based collaborations may expose sensitive information such as users’ locations and their roles within organizations, organizations collaborating, and their interests in specific topics.

This research is motivated by previous work on using blockchain to enable trustable collaboration between small and medium enterprises (SMEs) and research institutions in executing collaborative research projects [12]. Such a collaboration system and other similar collaboration systems, like research data sharing platforms [13], social manufacturing [14], collaborative modular construction [15], and procurement auditing platforms [16], need to be properly examined for their linkability problems with solutions that mitigate these problems. These types of platforms usually involve entities such as individuals or organizations working on a shared project or sharing specific data related to a project; hence, they will have potential linkability concerns.

The ZKP system provides a potential privacy-preserving mechanism for mitigating linkability in blockchain-based collaboration systems. ZKP systems provide mechanisms for verifying the correctness of transactions and actions executed on the blockchain without revealing complete information about the transaction [17]. In this way, only proof of the correctness of the transaction is stored immutably on the blockchain, and other parties can interact with this proof to verify that a particular transaction or execution logic is correct [18]. ZKP systems have been widely applied in blockchain applications to address linkability problems [5,19,20]. ZKP algorithms such as ring signatures, Merkle trees, Bulletproofs, and homomorphic encryptions have been widely used in blockchain systems in obfuscating transactions [21], proving membership of a group [22], verifying numbers in a range [23], and performing confidential calculations on-chain [24]. Some popular frameworks exist for realizing ZKP systems in smart contracts, such as Zero-Knowledge Succinct Non-Interactive Argument of Knowledge (zk-SNARKs ) and Zero-Knowledge Scalable Transparent Argument of Knowledge (ZK-STARKs) [25]. zk-SNARKs are more efficient in blockchain applications because they are non-interactive, require a smaller proof size, and are faster to verify, thereby resulting in lower on-chain transaction costs [26].

Notwithstanding the opportunity ZKP systems provide in addressing privacy issues in blockchain systems, there is still limited research in providing generic proof-based solutions to common linkability problems, especially for blockchain-based collaboration-enabling systems. To address this gap, this paper proposes the following research questions: How to design and implement privacy-aware collaborations on the blockchain through the integration of proof-based solutions to address linkability problems? The following sub-questions are derived: What are the recurring linkability problems in blockchain collaboration systems? What are the formal specifications of the recurring linkability problems? What is the prototype implementation of ZKP-integrated collaboration on blockchain to address linkability problems therein? By answering these research questions and addressing linkability problems in blockchain collaboration systems, the following contributions emerge from this paper: identification of linkability problems, formalization and categorization of linkability problems, identification of relevant ZKP algorithms, implementation of a proof-based solution that limits linkability problems, and comparative analyses of similar ZKP algorithms to identify performance issues. The rest of the paper is structured as follows. Section 2 provides technical explanations of blockchain technology and ZKP systems and also provides a review of linkability problems. Section 3 provides a systematic assessment of linkability problems in processes within blockchain-based collaboration systems. Section 4 provides a formal specification of linkability problems and outlines potential ZKP algorithms suitable for the specified problem. Section 5 shows the implementation of ZKP-integrated privacy-aware collaboration. Section 6 provides scenario-based evaluation of the PoC and comparative performance analyses of relevant ZKP algorithms. Section 7 discusses the main results of this work. Section 8 provides the conclusion, limitations, and future work.

2. Background and Literature Review

2.1. Related Technical Concepts

2.1.1. Blockchain Concepts

The blockchain concepts relevant to collaboration systems that are also applicable to this work include the blockchain network, where transactions representing outcomes of collaborations are stored; smart contracts for programming the logic and conditions of collaboration; and public key cryptography for user identification and signing of transactions.

-

Blockchain networks: This is an immutable ledger of a p2p network where transactions are stored [27]. Blockchain networks are broadly classified into two types: public networks and permissioned networks. In public networks, there is no restriction on who can join the network, and the transactions executed on the network are visible to the public. Permissioned blockchains, also referred to as private networks, require an invitation to join the network, and the transactions executed on the network are visible only to the participants. Although privacy leakage issues are common in public networks, linkability problems exist in both networks.

-

Smart contracts: they are computer programs that run on blockchain networks. They are self-executable and do not require a centralized entity to enforce business conditions, such as collaboration logic encoded in them [28]. Decentralized applications (DApps) can comprise one or multiple smart contracts; hence, collaboration systems built on blockchain are also referred to as DApps.

-

Public key cryptography: entities in a collaboration system, such as organizations and individuals, are identified by their addresses, which are short representations of a public key (or addresses). Public keys are derived from private keys, which entities participating in a collaboration can use to sign their transactions. In private blockchains, organizations act as certificate authorities and issue the keys to their members, while in public chains, keys are generated by the users themselves [29].

2.1.2. ZKP Concepts

The ZKP concepts relevant to this work are covered under the core principles of ZKP systems, the main components, and their general classifications.

-

Principle of ZKP systems: The core principles of a ZKP system are represented by the following properties: completeness, soundness, and zero-knowledge. Completeness is a condition that if a given statement is true, a prover can convince a verifier that the particular statement is true. Soundness refers to a condition where a dishonest prover is incapable of unilaterally convincing a verifier that a false statement is true. Zero-knowledge refers to a condition where a prover does not reveal any more information to the verifier about a statement except the fact that the statement is true [30].

-

Components of ZKP systems: There are three main elements in a ZKP system, including statement, proof, and verification. The statement comprises a claim that an honest prover needs to assert to an honest verifier that it is true. The proof is generated by a ZKP system and shared with the verifier to convince them that a given statement is true. Verification is a challenge–response mechanism where a verifier requires a prover to provide evidence to demonstrate that a statement is true [18].

-

Types of ZKP systems: ZKP can be broadly categorized into two types based on their proof verification mechanisms, such as interactive and non-interactive ZKP. Interactive ZKP comprises several back-and-forth challenge–response interactions between the prover and verifier in the process of verifying that a given statement is true. In non-interactive systems, only one single step of interaction is required for a prover to prove to the verifier that a claim is true [31].

-

zk-SNARKs Framework: The ZK-SNARK is a common framework for implementing ZKP systems on smart contracts with on-chain-based verification due to their efficiency. In zk-SNARKs, ZKP problems are translated into formal expressions represented as a mathematical circuit [32]. Circom is a programming language for realizing zk-SNARK circuits using high-level, human-readable expressions [33]. To verify proofs generated by zk-SNARKs, three items are required: the verification key derived from the formal circuit, the proof generated from the circuit that satisfies all the input conditions, and the public statement containing the selected input and output signals that are publicly visible. A smart contract-based verification script is used to validate the correctness of a proof, considering the public statement and the verification key provided [34].

2.2. Related Literature Review

2.2.1. Privacy-Aware Collaborations in Blockchain Systems and Privacy-Leakage Issues

Several privacy issues are associated with blockchain systems, especially when executing inter-organizational collaborations. In blockchains, transactions are generally transparent to the participants in the network [4]. Metadata describing specific blockchain assets can contain real-world information about the users, such as time stamps, IP addresses, etc. [6,35]. Conditions and logic encoded in smart contracts can reveal business processes and sensitive business secrets [6]. These privacy issues, when exploited by a malicious entity, can link multiple actions or transactions on a blockchain network to a single entity, thereby undermining users’ and organizations’ anonymity.

Several privacy-aware solutions have been proposed to address privacy issues, including off-chain data storage in public blockchains and private data channels in permission blockchains [7,36], decentralized identifiers (DIDs) and selective data disclosure mechanisms [37], self-sovereign identity mechanisms such as multi-factor self-sovereign identity authentication mechanisms (MFSSIA) [38], and access control mechanisms such as role- and attribute-based approaches [9,39,40]. However, linkability problems persist in blockchain-based collaboration systems. Role-based access control systems can potentially reveal functions connected to specific blockchain addresses of individuals in an organization. Self-sovereign identity systems do not prevent the traceability of addresses collaborating on a particular project. Selective disclosure of assets does not prevent a malicious entity from extracting organizational interests from the type and title of documents they share with collaborating parties. ZKP has been proposed as an ideal solution to several privacy leakage issues leading to linkability in blockchain systems [18]. Hence, the focus of the current paper is to understand various types of linkability problems in collaborative blockchain systems and relevant ZKP algorithms and frameworks suitable for addressing the identified problems.

2.2.2. Linkability Problems in Blockchain Systems

By analyzing several pieces of literature, this paper identifies seven main types of linkability problems that exist in blockchain systems. These include transaction and user type linkability, inter-organization collaboration linkability, role and responsibility linkability, data access and usage linkability, feedback and reputation linkability, location and time-based linkability, and lastly, project-specific linkability.

Table 1. Linkability problem types.

ID	Type Linkability	Summary	Articles
L1	Transaction/User type	tracing users through patterns in their transactions	[11,41,42]
L2	Inter-Organization Collaboration	exposing organizations’ partnerships and business relations	[4,43]
L3	Role and Responsibility	role-based actions exposing functions within organizations	[44,45,46]
L4	Data Access and Usage	accessed documents exposing business interest	[47]
L5	Feedback and Reputation	extracting characteristics of past collaborations	[48,49]
L6	Location and Time-Based	connecting transactions timestamps to geographic origin	[11,50]
L7	Project-Specific	associating users in shared project tasks	[43,51]

provides a summarized description of these linkability problems and the related literature they are extracted from.

The research [11,42] shows that by applying data mining techniques to transactions on the blockchain, transaction graphs containing several relationships can be extracted. The study [41] shows that analyzing interactions on a smart contract, their types, and clusters of user activities can reveal behavioral patterns. Hence, with repeated actions using the same identifiers (address), external actors can link actions to specific organizations and users, thereby affecting their privacy. This is classified as transaction/user-type linkability. The paper [43] on how blockchain technology enables collaborative workflows highlights the linkability problem that occurs when sensitive business relationships are revealed when organizations collaborate through blockchain-based systems. Also, when organizations collaborate, they exchange information assets where metadata of such assets could reveal sensitive business secrets [4]. These business partnerships, when explored further, can expose important business strategies and inter-dependency between organizations. This type of linkability problem is classified as inter-organizational collaboration.

Certain actions by entities in blockchain-based collaboration platforms, such as registering users, approving transactions, contributing to content, etc., can be specified to roles [44,45,46]. Repeated actions connected to a specific role can reveal an individual’s role or function in an organization. This type of linkability problem is classified as role and responsibility. Data and documents accessed by collaborating entities can reveal information about the interest of an organization in specific topics or their business needs [47]. Even when the data is encrypted, by analyzing the titles of such documents that members of an organization usually access or work on, an external actor can identify their business interests. This is referred to as data access and usage linkability. Collaboration systems often include reputation mechanisms where parties can provide feedback and rate each other’s performance. Such collaboration feedback systems, when implemented on the blockchain, can reveal characteristics of specific and past collaborations with respect to the collaborating entities [48,49]. For instance, one organization could have a good relationship with a particular set of organizations and a bad relationship with another group. This type of linkability is classified as feedback and reputation.

Location- and time-based linkability occurs in collaboration systems when time-stamped interactions reveal information such as user working hours, time zone, and other geographic data that can help in inferring the user’s location [11,50]. By performing network analyses on blockchain networks, the recurring timing of transactions can leak information about their origin [11]. Collaboration in a specific set of projects by sharing documents, working on the same tasks, etc., reveals users who are working together, and this is classified as project-specific linkability [43,51]. This type of linkability problem can expose strategic partnerships between individuals.

3. Assessment of Linkability Problems in Blockchain-Based Collaboration Systems

3.1. Analysis Criteria

For the analyses conducted in this section, some example blockchain-based collaboration platforms selected from previous works are analyzed. The linkability problem types identified in Section 2.2 are used as the analysis criteria. The goal is to identify privacy-preserving mechanisms that are applied when designing/implementing the selected collaboration platforms, and also identify linkability problems that persist on the analyzed platforms. The property Q1 checks if any privacy-preserving mechanisms have been applied, and Q2 checks if there are still linkability problems. The properties L1 to L7 check the linkability problems in the analyzed systems.

The article [15] implements a blockchain-based collaboration platform for modular construction operations through the integration of digital twin technologies. The goal is to provide model-driven design where interdisciplinary stakeholders, such as manufacturers, logistics companies, and building contractors, collaborate in the design of the digital twins of construction operations. The article [14] proposes a blockchain-enabled platform for social manufacturing and management of resources where social, cyber, and physical space entities collaborate to form a decentralized network. The article [16] describes a collaboration framework for auditing government procurement processes using blockchain technologies. The article [13] describes a collaboration platform where individuals, research teams, and institutions can securely share and access research data. The article [12] describes a blockchain-based collaboration platform for entities such as small and medium-scale enterprises and research institutions to manage and execute collaborative projects and store project-specific outcomes, such as reputations, on the blockchain. The paper [52] implements incentivized collaborative software development on the blockchain. The platform allows collaborators to earn contribution points by joining a project and performing software development tasks. The initial project participants can vote to allow new contributors and also vote to evaluate the quality of contributions of the project participants. The earned contribution points can be used to access other software projects on the platform.

3.2. Results of Analyses

The analysis results, as shown in

Table 2. Analyses of linkability problems in collaboration systems.

Article	Summary	Q1	Q2	L1	L2	L3	L4	L5	L6	L7
[15]	collaborative modular construction	no	yes	1	1	1	1	0	1	1
[14]	social manufacturing network	RBAC, permission-chain	yes	1	1	1	1	0	1	1
[16]	government procurement auditing	no	yes	1	1	0	1	0	1	1
[13]	research data sharing platform	ABAC, permission-chain	yes	1	0	1	1	0	1	1
[12]	sme and research institutions collaborations	ABAC, off-chain storage	yes	1	1	0	1	1	1	1
[52]	collaborative software development	no	yes	0	1	0	1	1	1	1

, show that linkability problems persist in all the blockchain-based collaboration systems analyzed. Privacy-preserving mechanisms adopted in these systems include the design of various access control mechanisms, such as role- and attribute-based access control, the use of permissioned blockchains, and the adoption of off-chain data storage for sensitive collaboration information. However, various linkability problems persist in these collaboration systems. The prominent linkability problem that affects all the systems is the project-specific and location linkabilities, followed by transaction/user-type linkabilities, while the least common is the reputation/feedback linkability. This is because most of the platforms evaluated do not consider the quality of contributions from the collaborating parties, except [12,52], which uses feedback rating and voting to assess the performance of collaborators. It is also expected that all the collaboration platforms analyzed will have project-specific linkability since all of them allow users to interact and complete shared tasks on the blockchain.

4. Formal Specification of Linkability Problems and Relevant ZKP Algorithms

4.1. Generic Solutions to Linkability Problems and Their Formal Translations

In this part of the paper, the identified linkability problems are assigned to generic proof-based solutions with their formal translations derived. Furthermore, the solutions are also classified into different types of proofs. As shown in

Table 3. Formalization of linkability problems.

ID	Proof-Based Solution	Proof Category	Formal Translation
L1	Prove a transaction a is part of a hidden set of transactions y	transaction obfuscation	$T\in \left\{\mathrm{Hash}\right(Py\left)\right\}$
L2	Prove that org A is part of hidden members of Project y	set membership	$A\in Py$
L3	Prove membership of a role	set membership	$A\in Pr$
L4	Prove access right	set membership	$A\in Pa$
	obfuscated data update/write	homomorphic calculation	$e\left(X\right).e\left(Y\right)=e(x+y)$
L5	Prove that A is qualified to give feedback	set membership	$A\in Py$
	Prove that it is the right time to give feedback	range comparison	$P_t\ge T\le P_t+\mathrm{delay}$
	Prove that a particular hidden feedback is given	homomorphic calculation	$e\left(X\right).e\left(Y\right)=e(x+y)$
L6	Prove that a participants location(timezone) is in allowed list	set membership	$A\in Py$
	Prove a transaction a is part of a hidden set of transactions y	transaction obfuscation	$T\in \left\{\mathrm{Hash}\right(Py\left)\right\}$
L7	Prove that party A is part of a set of people in Project y	set membership	$A\in Py$

, L1 linkability can be addressed by obfuscating transactions in sets before storing them on-chain. Transaction T can be hidden in a root hash of other transactions, $Py$. L2 can be addressed by hiding collaborating parties in a set of members and proving membership of the hidden group before executing any related function. Hence, a member A can be part of a hidden set $Py$. The same applies to L3, where roles and membership of a role can be stored in a hidden set. For L4, members in a writing group can be stored in a hidden set, while the update performed on specific documents can be obfuscated in the form of homomorphic calculations. The hidden summation of $x,y$ can be represented as homomorphic multiplication of encrypted $e\left(X\right)$ and $e\left(Y\right)$. For L5, a set of hidden members can be used to prove that a user is qualified to provide feedback, a range-based comparison can be used to prove that it is the right time to provide feedback, while obfuscated homomorphic calculations can be used to compute the feedback result (assuming a quantitative feedback rating). The same formal representation of set membership and homomorphic calculation applies. For range representation, given a project closing time $Pt$ and allowed delay d for before which rating must be given, current rating time $Ct$ must be greater than or equal to $Pt$ and less than or equal to $Pt+d$. This ensures that feedback is provided, revealing the user, the time the rating is given, and the actual individual rating score. For L6, the location information of users is not stored along with their transactions; rather, users can prove their location is in an “allowed list” before registering on the collaboration platform. The transactions generated by each user can be aggregated and obfuscated with the other users’ transactions and stored at specified intervals. L7 can be addressed by proving membership in a hidden set of people in a project before executing project-related functions. The already expressed formal representations for set problems and root transaction hash obfuscation apply to L6 and L7.

4.2. Relevant ZKP Algorithms and Frameworks

From the preceding analyses, there are three main problem types in blockchain-based collaboration systems that ZKP is required to address, including proving membership of a group, range comparison, and homomorphic calculation.

Table 4. Mapping ZKP problem types to algorithms and frameworks.

ID	Problem Type	ZKP Algorithm	Smart Contract Framework
1	Membership of a set	Merkle tree	zk-SNARKs Merkle tree
2	Range comparison	Bulletproof	zk-SNARKs logical comparison
3	Homomorphic arithmetic	Pailler encryption	-

outlines these problem types and relevant ZKP algorithms and smart contract frameworks for implementing them on the blockchain. Although zk-SNARKs and zk-STARTs are two common general frameworks for developing zkp applications, zk-STARKs are not generally suitable for blockchain applications due to their large proof sizes and multi-step challenges and responses during the proof verification. Hence, zk-STARK is used as a suitable framework for developing various proofs relevant to this research.

4.2.1. Set Membership Proof

Membership of the group can be securely proven with the Merkle root, where the root that is derived from a given leaf (a single member) and the path to the root is equivalent to the initially provided Merkle root [53]. Given a set of n members, each member in the set can be represented as $S_i=S_1,S_2,\dots .S_n$. Each member can be represented by their hash $H_1=H_{\left(s_1\right)},H_2=H\left(s_2\right)\dots H_n=H_{\left(s_n\right)}$. The parent nodes are calculated as follows until k steps to derive the Merkle root: $H_{21}=H\left(H_1\Vert H_2\right),H_{22}=H\left(H_3\Vert H_4\right)\dots {H_2}_{\left({\displaystyle \frac{n}{2}}\right)}=H\left(H_{\mathrm{n}-1}\Vert H_{\mathrm{n}}\right)$, where $k={Log}_{2}n$. The verification of a Merkle tree is the calculation of the path to the root from the given leaf node, as shown in Equations (1) and (2), where the calculated root from the leaf path is expected to be equivalent to the originally derived root.

$$R^{\prime }=H_k\left(\dots \left(\left(H\left(H\left(s_i\right)\Vert H_1\right)\right)\Vert H_2\right)\Vert {\dots H}_{k-1}\right)$$

(1)

$$R\prime ==R$$

(2)

A prover has to disclose to the verifier at least one member of the set and the subsequent path hashes before verification is completed. However, when Merkle proof is implemented using the zk-SNARK framework with Circom Template Merkle Tree Verification: https://github.com/thor314/circuit-examples/blob/main/circom-merkle-proof/verify-merkle-path.circom (accessed on 1 June 2025), a prover can choose to selectively disclose only one member of the set (or no member of the set) in proving membership of a set. Hence, the proof and the Merkle root are enough to verify group membership. The public statement will comprise the root and a leaf (which is optional), the proof that is derived (if the input data, i.e., the leaf and root path, satisfies the conditions of the circuit), and the verification key generated directly from the formal circuit of the Merkle proof.

The main security argument in the Merkle tree algorithm is that it provides a guarantee for data integrity and unforgeability in proving membership in order to provide a feedback rating. This is because the Merkle root links all legitimate project participants, and each participant has their unique proof (path elements and index) that connects them to the Merkle root. This is guaranteed by its knowledge soundness and underlying collision resistance.

4.2.2. Range Proof

Bulletproof provides a system for verifying numbers within a specified range by using the inner product argument, which is the sum of the bit-wise multiplication of a vector derived from the compared numbers, in generating proofs [23]. X lies in the boundary of n where $X\in \left[0,n-1\right]$, if the summation of the bit-wise multiplication of the vector of the binary of X and powers of 2 of m is less than $n-1$, where m is the binary length of the upper boundary n and is computed as $m=lo{g}_2\left(n\right)$. The binary of X is considered the left side of the vector L, while the powers of m are the right side R. X is decomposed into its binary representation, where the vector product of X binary and the upper boundary binary range is given by Equation (3), and the elements of X must either be 0 or 1; hence, $x_i\in \{0,1\}$. Therefore, the left side of the vector is represented as Equation (4), and the right side as Equation (5).

$$X=\sum _{\left\{i=0\right\}}^{\left\{m-1\right\}}{2}^i{x}_i$$

(3)

$$L=\left(x_0,x_1,\dots ,x_{\left\{m-1\right\}}\right)$$

(4)

$$R=\left(2^0,2^1,\dots ,2^{\left\{m-1\right\}}\right)$$

(5)

If X is less than n, then $〈L,R〉$, the sum of the vector multiplication of L and R, is given as $X=(x_0.2^0+x_1.2^1\dots {2^{m-1}.x}_{\left\{m-1\right\}})$ is less than or equal to $n-1$. The vectors L and R are recursively reduced by half with a scalar random number until their base values and the number of reduction steps are given by $lo{g}_{2}n$, where $〈L^{\prime },R^{\prime }〉$ represents the final reduction of the vectors. Hence, the proof is done by reverse calculation of $〈L^{\prime },R^{\prime }〉$ until the original values of $〈L,R〉$, which are used to derive X. Using the zk-SNARK framework, range proof can easily be realized with the Circom Comparators template and Circom Comparators templates: https://github.com/iden3/circomlib/blob/master/circuits/comparators.circom (accessed on 1 June 2025), where the input signals represent the values that need to be compared, the output is the logical outcome of the comparison, while the public statement represents the selection of the input signals that will be publicly disclosed.

The main security argument for bulletproofs is that sensitive information that is quantifiable can be kept private, while a range of numbers is used to describe the hidden information. The security argument is guaranteed by the assumptions within the discrete logarithm, which Bulletproofs are based on, and the soundness of its knowledge.

4.2.3. Homomorphic Calculation

Homomorphic cryptography provides techniques for performing computational arithmetic on encrypted data without the need to first decrypt the encrypted data [54]. In Paillier cryptography, the proof for homomorphic addition is that the encrypted sum of two separate numbers $e(X+Y)$ is the same as the product of each of the encrypted values $e\left(X\right)·e\left(Y\right)$. Hence, the encryption of X and Y values is given as shown in Equations (6) and (7), where g is a generator, $r,s$ are random numbers, and n is part of the public key used in the encryption.

$$e\left(X\right)=g^X·r^{n}mod{n}^2$$

(6)

$$e\left(Y\right)=e\left(Y\right)=g^Y·s^{n}mod{n}^2$$

(7)

The homomorphic addition of the generated ciphers of X and Y is given as $e\left(X\right)·e\left(Y\right)=\left(g^X·r^n\right)·\left(g^Y·s^n\right)mod{n}^2$; hence, $e\left(X+Y\right)=g^{X+Y}·{\left(r·s\right)}^{n}mod{n}^2$. The decryption of the resulting cipher is represented as Equation (8), where D is the private key. For the verification of the cipher, the following logic applies, as shown in Equation (9).

$$D\left(e\left(X+Y\right)\right)=X+Y$$

(8)

$$e\left(X\right)·e\left(Y\right)==e\left(X+Y\right)$$

(9)

However, true homomorphic arithmetic is not possible on the zk-SNARK framework. Although the Poseidon hashing technique, which is commonly used in the SNARK framework, results in a big integer of a hashed number, it is still not possible to perform homomorphic arithmetic on the generated number since hashing is one-directional [55].

In Paillier cryptography, the security argument is that privacy preservation is achieved through encrypted aggregation of numbers, either for addition or multiplication cases. Both the number and the outcome of the arithmetic operation on the number are hidden. Unlike the Merkle tree and Bulletproofs, the Paillier homomorphic calculation lacks knowledge soundness, where a prover can convince a verifier of the correctness of a statement by having underlying secret information that makes the statement true. Instead of a prover and verifier, there is a homomorphic operator.

5. Implementation of Privacy-Aware Collaboration Process on Blockchain

5.1. Selection of Collaboration Process

The linkability in feedback reputation mechanisms in blockchain-based collaborations covers the identified three problem types that can be addressed with ZKP, including proving membership of a set, proving a number within a range, and obfuscation of data in arithmetic calculations (see Table 3 and Table 4). The goal is to design and implement a blockchain-based feedback system that enables project collaborators to securely provide feedback on a completed project without being linked to any action in the feedback process.

Figure 1 shows an algorithmic flowchart for implementing a privacy-aware feedback reputation system on blockchain without any linkability to the project collaborators. The feedback process starts with the completion of a collaborative project, before the project participants can provide feedback ratings. No ZKP proof is required for this part, as the project completion can be set and the project completion time $\left(P_t\right)$ noted. The first check verifies that project participants $x,y,z$ are part of the project participants $P_p$. This check is implemented with zk-SNARK Merkle membership proof. If the first check is $TRUE$, the algorithm proceeds to the second check, which verifies that the feedback rating is submitted within the allowed time. Hence, the current time of the rating $C_t$ must be greater than the project completion time $P_t$ and allowed delay $P_t+d$. This can be implemented with zk-SNARK comparators’ proof. If the second check returns $TRUE$, the last step involves homomorphic calculation of the encrypted rating submitted by each participant $x,y,z$ after the three verification steps are completed for each of them. The first check can be referred to as algo1, the second check as algo2, and the homomorphic calculation as algo3. Assuming the ratings are first aggregated off-chain with the proof of their submission time, $C_t$ does not need to be recorded on-chain since the calculation of encrypted ratings and their time validation proofs can be sequentially computed on-chain.

5.2. PoC Prototype

5.2.1. Simulation Setup and Tools Required to Implement the Proposed System

To develop the algorithms for the prototype, we used the Circom language Circom Documentation: https://docs.circom.io/circom-language/templates-and-components/ (accessed on 1 June 2025) for generating the SNARK circuits for the proofs and Solidity smart contracts for verifying the proofs, and also for the homomorphic calculation. To implement these programs, the REMIX online IDE REMIX Documentation: https://remix-ide.readthedocs.io/en/latest/ (accessed on 1 June 2025) is used to provide support for both smart contracts and ZKP SNARK. Circom files are saved as reusable templates. There already exist templates for range and Merkle set membership verifications. These templates are adapted for the algorithms used in this work. With the REMIX ZKP Circom compiler, all intermediary files required for ZKP SNARK verification can be generated automatically after compiling a Circom template. Some of the relevant files include the verification key (JSON), proof (JSON), and public statement (JSON), all in JSON format, and the verifier smart contract (Solidity). For code readability, the Circom and Solidity codes used in proof generation can be found in the GitHub project repository ZKP Feedback System: https://github.com/cjobuzor/ZKP-feedback-system/tree/main (accessed on 1 June 2025).

5.2.2. Proof Generation

-

Circom codes for proof 1 generation: The purpose of the first proof is to calculate, given the inputs, if a Merkle tree is valid. This ensures that a prover can prove membership of a group (set) by only providing one member of the set and the Merkle root of the set. The Circom code used to realize the SNARK circuit for the proof is shown in Figure 2.

The code takes the following input signals: leaf, root, path elements, and path indices. The leaf represents one member of the set, which in this case is the hashed wallet address of the prover. The root is calculated as the Merkle root of the addresses in the set (participants X, Y, and Z). As shown in the flowchart in Figure 1, three participants are expected to participate in the project and provide ratings; hence, a null value of zero is added to the set to complete the four members required in the Merkle tree. The path elements contain the pair of the provided leaf and the subsequent paths to the root of a Merkle tree. The path indices are binaries of 1 and 0 representing the side path elements from the leaf towards the root. The output is a logical assertion that ensures that the Merkle root calculated from the input data (leaf, path element, and path indices) is always equivalent to the Merkle root provided in the public statement. Otherwise, the proof fails. Hence, the public statement, which is the part visible to the verifier, is the root and the leaf. The flowchart in Figure 3 shows a comprehensible algorithm for proof of membership generation.

-

Circom codes for Proof 2 generation: The purpose of the second proof is to verify that the time at which a participant is submitting a feedback rating is valid using a range proof. The time is expected to fall within the project closing time and the delay allowance. The Circom code for realizing the SNARK circuit is shown in Figure 4.

The following input signals apply to the second proof: project closing time (a), delay (d), and the rating time (b). The output checks two logical assertions that are expected to be true. The first ensures that the rating time is always greater than the project closing time, and the second ensures that the sum of the project closing time and the allowed delay is always greater than the rating time. Otherwise, the proof fails. The public statement is the project closing time and the allowed delay, since the participants do not want to reveal who rated first. It is also assumed that the ratings are aggregated off-chain and submitted on the blockchain. Hence, the participants cannot infer each other’s rating times or the actual ratings. The flowchart in Figure 5 shows a comprehensible algorithm for the range proof generation.

5.2.3. Proof Verification Smart Contracts

The verification smart contracts for the ZKP proofs are automatically generated from the ZKP SNARK compiler. The verification requires the verification key, proof, and public statement to compute correctly. For this experiment, we utilized the SNARK GROTH16 library [56] to construct the SNARK circuits and verify the proofs. The verification key is first generated after building the circuits from the Circom templates, while the verification smart contract is generated after the proof is computed from the instantiated input signals of the circuit. The verification key is encoded as part of the smart contract and deployed on the blockchain. Hence, the proof and public statement are provided as inputs for the verification smart contract. This setup works for experimental purposes, as the reverse may be the case in a production environment. Verification of ZKP SNARK proofs is a computationally expensive task; hence, it is more logical that the proofs and public statements are stored on-chain while the verification script (including the verification key) is executed off-chain. Three types of interactions could occur between the verifier automatically generated by the Circom compiler and blockchain components. The verifier can be deployed as a smart contract and receives proofs stored off-chain. Another option is that both the verifier and the proof storage are on-chain components, where the smart contract directly interacts with a proof stored on the blockchain. The last interaction option is that both the verifier and proof storage are off-chain components, while the outcome of the verification is stored on the blockchain. For the demonstrated simulation of the PoC carried out in the latter part of this work, the second interaction option is used, where the verification is a smart contract that receives proofs stored off-chain.

The GROTH16 ZKP proofs consist of three points (A, B, C) in an elliptic curve that satisfies a pairing equation. To verify the correctness of a proof, these points are paired with components of the verification key. The result derived from pairing must always satisfy the elliptic curve equation that encodes the computation correctness of the arithmetic circuit of the proof. For the verification of the first two proofs (range and set membership), verification smart contracts are generated for each of the GROTH16 proofs.

5.2.4. Homomorphic Calculation of Rating

The homomorphic calculation of the ratings involves three steps: the generation of encrypted ratings, the summation of the encrypted ratings, and the decrypted average of the ratings using Paillier cryptography. The first and last steps are performed off-chain using scripts, while the second step of summing the submitted ratings is performed on-chain using the smart contract. This is necessary such that private information used for generating and decrypting the ciphers is not publicly available on-chain. The following parameters are used for generating the public key and private keys necessary to encrypt and decrypt Paillier ciphers: public key $n,g$ and private key $lambda,mu$.

-

Submission of Encrypted ratings: the encrypted ratings of the participants are given as Px = $g^X·r^{n}mod{n}^2$, Py = $g^Y·r^{n}mod{n}^2$, and Pz = $g^Z·r^{n}mod{n}^2$, assuming three project participants. Where g & r are random generators, n is the product of two large prime numbers, and X, Y, and Z are different ratings submitted by the participants. A script that implements these encrypted calculations is used to generate the rating ciphers off-chain.

-

Homomorphic calculation of rating sum: the contract accepts the inputs $a,b,n$, where a is the first encrypted input, b is the second encrypted input, and n is the public key component of the product of two large prime numbers. The encrypted sum is calculated as shown in Equation (10), where a and b represent the encrypted ratings submitted by the participants, such as Px, Py, and Pz.

$$Enc\left(a\right)·Enc\left(b\right)(mod{n}^2)$$

(10)

The encrypted summation is implemented in the smart contract shown in Figure 6. The function addEncRating is called multiple times, representing the number of participants (N) that submitted encrypted ratings. The calculated encrypted sum is added to the next encrypted rating until all the participants’ ratings are included.

-

Decrypted average rating: the final rating is derived by decrypting the summed ratings and dividing by the number of participants, N. The decryption script implements the following calculation using Paillier parameters: cipherSum (c), lambda ($\lambda$), n, and mu ($\mu$). The decrypted rating sum is given as the total rating (Tr) provided by the participants, and it is calculated as shown in Equation (11). The average rating (Ar) is given as the decrypted sum divided by the number of participants, as shown in Equation (12).

$$Tr=(\left(c^{\lambda }(mod{n}^2)\right)-1)/(n·\mu (modn))$$

(11)

$$Ar=Tr/N$$

(12)

A script that implements these calculations is used to generate the average rating off-chain. The flowchart in Figure 7 shows a comprehensible algorithm for the homomorphic calculation of the ratings.

6. Evaluation of the ZKP Feedback System

This paper adopts scenario-based simulation to evaluate the ZKP PoC developed for the privacy-preserving feedback system in a collaboration setup. Scenarios are created such that the project participants are able to generate proofs of their membership in a project and on-time submission of ratings, and the system verifies the proof and calculates the encrypted calculation of ratings. Also, performance-based evaluation is adopted to compare alternative proof-based solutions in terms of proof sizes and execution costs.

6.1. Scenario-Based Evaluation

6.1.1. Scenarios and Simulation Data

Three scenarios are used to simulate and demonstrate the privacy-aware feedback system. In the first scenario, the participants of the projects (p1, p2, p3) can correctly prove their membership and submit encrypted ratings within the required time frames, and the system correctly verifies their submitted proofs to calculate the average ratings. In the second scenario, all the participants correctly proved their membership; however, one of the participants (p3) submitted the rating late. In the third scenario, a fake member (p4) submits a feedback rating for the project without being able to prove membership in the project.

For the membership proofing, the participants (p1, p2, p3, p4) are identified by their blockchain wallet addresses, which are then hashed with Poseidon to generate the suitable integers for the zk-SNARKs set membership proof Circom code. The Merkle root is calculated for the true participants (p1, p2, p3). The project closing time and the allowed delay are represented in milliseconds. The same random numbers (g, r) and prime numbers (P, Q) are used to generate the public key and private key parts for Paillier’s encryption of the ratings by the participants. The instantiation of data used in the simulation is provided in

Table 5. Simulation input data.

Data	Instantiation
p1	2607538832365938183856912999939015116234908276820668911759788692909015437942
p2	7899789289387013027401636618414331284908183383275772295487478478746557180631
p3	12209633184300546939521755067155096206083595833408888480612381107524453678017
p4	3830441202945463825368553390859023432014352879692332554139785969350624472337
root	6026600657574599622234885094606098830268178182044843874147816826344383946431
Pt	174,781,2842,000 (milliseconds)
delay	86,400,000 (milliseconds)
P, Q	(43, 41)
g, r, n	(104, 89, 1763)
$\lambda ,\mu$	(840, 1296)

.

6.1.2. Simulation Results

Three main simulation results are obtained from the scenario-based evaluation of the ZKP privacy-preserving feedback system. The first is the generation and validation of the proof of membership for the participants. As shown in Table S1 of Supplementary Materials, the result shows that the correct proofs and validations are obtained for all participants except p4 in scenario 3. This is because p4 is unable to correctly generate a proof of membership. The second simulation result, as shown in Table S2 of the Supplementary Materials, shows that the correct proofs and validations are obtained for all the participants except p3 in scenario 2. This is because p3 submitted the ratings late, beyond the allowed period of submission, hence unable to generate proof of on-time submission. The third simulation result, as shown in

Table 6. Simulation results of encrypted rating calculation.

		Validity	Validity	Ratings	Calculation	Calculation	Rating
Participant	ID	Proof 1	Proof 2	Encrypted	EncryptedSum	Decrypted/N	AveRating
scenario 1	P1	TRUE	TRUE	3,105,344	1,896,319	260/3	87
	P2	TRUE	TRUE	2,611,934
	P3	TRUE	TRUE	882,849
scenario 2	P1	TRUE	TRUE	3,105,344	79,656	165/2	82.5
	P2	TRUE	TRUE	2,611,934
(late submission)	P3	TRUE	FALSE	882,849
scenario 3	P1	TRUE	TRUE	3,105,344	1,896,319	260/3	87
	P2	TRUE	TRUE	2,611,934
	P3	TRUE	TRUE	882,849
(fake member)	P4	FALSE	TRUE	2,850,694

, summarizes the simulation outcome and provides the final feedback rating result for all the scenarios. For the first scenario, all the encrypted ratings provided by the three participants are used in calculating the final rating. In the second scene, due to a late submission by one participant, only the encrypted ratings submitted by two participants are used in calculating the final rating. For the last scenario, although encrypted ratings are submitted by four participants, only the ratings provided by the three legitimate participants are used in calculating the final ratings. A detailed explanation of the tables derived from the simulation results is provided below.

Tables S1 and S2 show the simulation results obtained for proof 1 and proof 2, respectively. The columns show the participants information (and simulation scenarios), the input signals used in generating the proofs, the proof data representing the three points of the elliptic curve (a, b, c), the public statement in hexadecimal for the smart contract to verify the proofs, and the last column represents the outcome of the proof verification.

For the proof of the membership simulation results (Table S1), the input signals represent the leaf, the Merkle root, and the path indexes to verify the membership root, while the public statement consists of the leaf and the root. For the simulation results of the on-time submission of the rating (Table S2), the input signals represent the project closing time, delay, and the current status of the rating submission, while the public statement consists of the project closing time and delay.

Table 7. On-chain simulation costs.

Cost Type	Gas Source	Membership Verification	on Time Verification	Rating Calculation
	gas	454,061	454,075	1,492,581
deployment cost	transaction cost	394,835	394,847	1,297,896
	execution cost	316,353	316,353	1,153,998
execution cost	gas	195,834	195,834	26,921

shows the costs associated with smart contracts to verify the membership proof, the submission of the letter on time, and the homomorphic calculation of the ratings. Two types of costs are associated with these smart contracts, including the deployment and execution costs. The deployment costs are gas fees connected with uploading the contract on the blockchain, while the execution costs cover the gas fee resulting from calling the verification and calculation functions in the contracts.

6.2. Performance Evaluation of ZKP System

6.2.1. Alternative Proof-Based Solutions

The zk-SNARKs algorithm used in developing the PoC can be compared with other similar algorithms for membership and range verifications. As already shown earlier in this work, the conventional Merkle tree can be used to verify project memberships, while Bulletproofs can be used to verify on-time submission of ratings. The proof sizes and on-chain verification costs of these algorithms can be compared with those of similar zk-SNARK algorithms.

For the proof of membership comparative evaluation experiment, to compare the performance of zk-SNARKs and a conventional Merkle tree, the number of project participants (set size) is gradually increased from 4 to 1024, and the size of the proof and verification cost is measured. For the proof of the on-time rating submission comparative evaluation experiment, the allowed delay is gradually increased from the initial 86,400,000 milliseconds to 22,118,400,000 milliseconds. The project closing time is kept constant at 1,747,812,842,000 milliseconds. Hence, the upper boundary is the summation of the incremental delay and the project closing time. The current time (submission time) is also kept constant at 1,747,823,642,000 milliseconds. The proof size and the verification costs are both recorded for Bulletproof and zk-SNARK range proof.

6.2.2. ZKP Proof Membership Comparative Evaluation Results

To perform this experiment, a Merkle proof generator for the first element (leaf) in the group is created. A smart contract that verifies proof provided for the first element in any given set is used. For the Merkle tree, the proof data includes the proof (path elements) and the public statement of the proof (Merkle root and leaf). For the Merkle tree derived in zk-SNARKs, the proof data includes the proof (three points in the elliptic curve) and the public statement (Merkle root and leaf). The proof elements and public statements are represented in JSON format. Each element in the proof is represented separately. For zk-SNARK, the JSON elements include root, leaf, Proof_a, Proof_b, and Proof_c, where a, b, and c are three points of the elliptic curve. For the Merkle tree, the elements include root, leaf, Proof_1, Proof_2, …, Proof_n, where n is given as $LOG2\left(P\right)$ and P is the size of the members. Where Proof_1, Proof_2, …, Proof_n are path elements until the root. The size of the proof is recorded in bytes, while the execution cost is in EVM execution gas.

Table 8. ZKP performance analyses.

	zk-SNARKs			Merkle Tree
Increase P	Proof Size	Execution Cost	logCost	Proof Size	Execution Cost	logCost
4	232	195,834	5.29	232	2513	3.40
8	232	195,834	5.29	232	3234	3.51
16	232	195,834	5.29	232	3955	3.60
32	232	195,834	5.29	360	4676	3.67
64	232	195,834	5.29	360	5398	3.73
128	232	195,834	5.29	360	6119	3.79
256	232	195,834	5.29	360	6840	3.84
512	232	195,834	5.29	360	7562	3.88
1024	232	195,834	5.29	640	8283	3.92

and Figure 8 show the experiment results for the comparative performance of the conventional Merkle tree and zk-SNARK-derived Merkle tree, showing the changes in proof size and execution costs as the set membership increases.

6.2.3. ZKP Proof On-Time Rating Submission Comparative Evaluation Results

An experiment can be designed to gradually increase the delay and measure proof size and verification costs to compare the performance of Bulletproof and zk-SNARK range proofs. Bulletproof performance depends on commitment value (v) and N such that the Pedersen commitment of the value (Cv) will always be less than or equal to 2(exp)N. Hence, for this case, v can be obtained by subtracting the upper boundary $Pt+delay$ from the $Ct$. By applying Pedersen encryption on v to derive Cv, the bit length of the range (N) that satisfies the condition that Cv is less than or equal to 2(exp)N, which depends on the keys used in generating the Pedersen commitment. Therefore, an indirect approach is used to compare the performance of Bulletproof and zk-SNARK for this work.

The elements in a Bulletproof include the Cv, left and right side elements <L_i, R_i>, and the final reduction elements (a, b). The proof size and verification cost will increase by 2*log2(N + 3). The work [57] already provided performance analyses showing the proof size and verification cost changes with increasing N. Using the same JSON storage format for zk-SNARK and Bulletproof, the proof size increases from 136 bytes (for N = 8) to 932 bytes (for N = 64), while the proof size of zk-SNARK is constant at 192 bytes (excluding the public statement parameters). The verification cost of a Bulletproof with N = 32 is over 2 million in gas costs, while the verification cost of zk-SNARKs is around 200 thousand in gas costs. This shows that zk-SNARKs have better performance both in proof size and verification costs than Bulletproofs.

7. Discussions

7.1. Research Implications

-

Effectiveness of the ZKP-Based Feedback System Prototype: The simulation results demonstrate that ZKP-based algorithms can be utilized to design and implement privacy-preserving collaborations within blockchain systems. For feedback and reputation systems, the proof-based system ensures that only project participants can provide feedback, ensures on-time submission, and calculates the final ratings or reputation score without revealing any data that links the participants to the feedback system. Although the feedback score used in the proof of concept is a simple average, the approach adopted in this paper can be applied to more complex reputation scoring systems on blockchain [58,59].

The performance evaluation results for the selected three algorithms required for the privacy-preserving feedback mechanism, as shown in Table 7, show high execution costs. Further comparison evaluation between the zk-SNARKs framework, the conventional Merkle tree, and Bulletproofs shows that zk-SNARKs have much better proof size and execution costs than Bulletproofs; however, the verification execution costs in the conventional Merkle tree are much cheaper. Still, these high execution costs associated with on-chain verification of proofs can limit the industry adoption of ZKP, systems such as the proof-based feedback system developed in this paper. A practical optimization approach is to store only the proofs and associated proof data on-chain while the actual verification is performed off-chain. Also, by deploying these high-cost applications on layer two scaling solutions, the execution costs can be considerably reduced [60].

-

Other Research Contributions: The results obtained in this research contribute to the usability of ZKP systems in blockchain applications. ZKP systems are quite complex and are commonly used in protocol-level blockchain applications, including scaling solutions like roll-ups, privacy-preserving cryptocurrencies such as coin mixers [61,62], and limited usage at the application level. The systematic approach adopted in identifying relevant ZKP algorithms and the implementation of the PoC feedback system ensure that this approach can easily be extended to implement other use cases of privacy-preserving operations in collaborative project executions and other inter-organizational processes. The ZKP algorithms developed in the PoC of this paper can be applied to ensure privacy preservation in operations involving data access rights, role responsibilities, and location- and time-based applications since they address critical problems such as proof of membership, proof of range, and encrypted arithmetic, as earlier identified in this paper. Furthermore, the results from this work can be extended beyond linkability problems in blockchain collaboration systems to sustainability verifications in supply chains. Some of the claims in digital product pass (DPP) systems, such as CO₂ footprint level [63], ethical raw material sourcing [64], etc., can be verified in a privacy-preserving way by adapting the algorithms developed in this work. For instance, the range proof algorithm in the PoC can be adapted to verify that the carbon footprint of a product is within the required level without revealing the actual number to the competitors.

7.2. Discussion on Evaluation Results of the ZKP System

-

Performance evaluation: Performance evaluation, including metrics such as proof generation time and proof size, is a well-known approach to evaluating ZKP-based systems [18]. For the zk-SNARK framework adopted in this work for generating and verifying the proofs for the first two algorithms (membership proof and on-time rating submission), the proof generation is done off-chain. Also, for the Paillier cryptography used for the third algorithm (homomorphic rating calculation), the private keys used in encryption and decryption of the cipher ratings are stored off-chain. Hence, proof-generation time does not provide an important metric for evaluating the blockchain system developed in this work. For the proof sizes, the proof can be stored on-chain, and the verifier smart contract reads directly from the blockchain. Alternatively, the proof can be generated off-chain and stored off-chain, and the entities that need to be verified can provide a signed proof as an input to the verifying smart contract. The latter is the case for the PoC concept developed in this work. Hence, the deployment costs for the smart contracts and gas costs for the executions provide a more meaningful performance analysis of the ZKP algorithms developed in this work. Table 7 shows the recorded deployment and execution gas fees associated with these smart contracts. The deployment and execution costs for algorithms 1(zk-SNARK membership verification) and 2(zk-SNARK range verification) are both similar in gas fees since the proof size and verification of smart contracts for zk-SNARKs are the same for all problem types. Deployment of the Paillier homomorphic calculation contract has a much higher gas cost in comparison to the zk-SNARKs verification contracts; however, the former has a much lower execution cost in comparison to the latter. The high deployment costs of the Paillier contract are connected to the large data size required for encrypted data, which is usually larger than plain text. Also, since zk-SNARKs proof verifications have high execution costs, it is possible that only the proof data is stored on-chain, while the verification is computed off-chain. However, this is not applicable to the ZKP feedback system designed in this paper, since the validity of proofs will determine if the homomorphic contract uses the ratings submitted by the prover in calculating the final feedback rating. Moreover, the goal of this paper is not to optimize the performance of ZKP algorithms but rather to demonstrate relevant ZKP algorithms for designing privacy-aware collaboration systems. Still, some approaches can be adopted to reduce the gas costs, such as optimizing the ZKP solidity codes and deploying layer two networks [60,65].

-

Privacy preservation: The level of privacy preservation achieved with the usage of ZKP is another important property for evaluating ZKP systems [19]. For the zk-SNARKs proof, the data exposed is visible on the public statements, as shown in the simulation data Tables S1 and S2 for verifying membership and on-time rating submission. For verifying membership, only the leaf and Merkle root of the members are exposed, while in on-time verification, the time boundaries, which are the project closing time and allowed delay, are exposed. Either of these two proofs can also be verified with only one item in the public statement; for instance, in the membership verification, the Circom code can be written such that only the Merkle root is in the public statement. This is possible because both verifications (membership and range) have no output signal defined but assert logical checks of the required conditions. Hence, zk-SNARK verifications implemented in this work have very high privacy preservation with a more configurable selective disclosure property. Paillier cryptography code used in calculating the homomorphic rating sum also has strong privacy preservation since only encrypted ratings are exposed to all the users and the public key component N, which is the product of the selected prime numbers. This allows anyone to verify the encrypted sum calculation since the encrypted sum can be calculated with the encrypted numbers and N. However, unlike zk-SNARKs proof verifications, Paillier homomorphic sum calculation lacks the selective disclosure property.

7.3. Discussions of Results with Other Similar ZKP Systems

-

ZKP in collaboration systems: Some earlier works have applied ZKP approaches in solving linkability problems in blockchain collaboration systems. The paper [66] proposes a sealed bidding ZKP system that ensures the privacy of bids using Pedersen commitments. The bidders reveal to the auctioneer the secrets to decrypt the bids and identify the maximum bid. For the other participants, the auctioneer must prove to the competitors that the selected bid is the maximum bid without revealing the actual bid. Proving the maximum number is considered a range problem, such that the selected number is greater than all the other numbers in the range. This is achieved using the additive homomorphic feature of the Pedersen commitment scheme. However, this paper addresses homomorphic cryptography and range problems differently. The comparators check in zk-SNARK are used as range proofs to verify that the submitted ratings are within the timeframe and use Paillier homomorphic addition to compute the overall valid ratings submitted by the participants. Both works (this paper and [66]) demonstrate the usage of similar ZKP algorithms to address different privacy problems.

The paper [67] describes an identity authentication and reputation system in a p2p marketplace, proposing ZKP to ensure that user identity credentials and documents shared in the collaboration network cannot be linked to the user and also to ensure KYC compliance without revealing much information about the user. The paper also assessed the complexities of various ZKP frameworks and algorithms like Bulletproofs, zk-SNARKs, zk-STARKs, etc., for selection in implementing the PoC of the identity authentication; however, a review of the algorithms and flowcharts in the paper does not show any real ZKP integration. In this work, ZKP algorithms were systematically selected by formalizing and mapping linkability issues to relevant ZKP algorithms. The relevant ZKP algorithms were used to implement a privacy-preserving feedback mechanism PoC.

In collaboration systems for drug delivery in the healthcare supply chain, the paper [68] uses the ZKP system to perform a compliance check on the product without revealing the full product information to the verifier. This ensures that the authenticity and quality of the product are maintained across the supply chain. Other works applied ZKP in non-collaborative systems, such as in IoT data transmission and cloud-based data retrieval systems. The paper [69] uses ZKP to check the firmware execution logic and ensure the integrity of data transmission in IoT devices. Such that when IoT devices are compromised, it will be impossible to generate the correct proof of the original execution logic in the IoT device. The paper [70] cloud-based system for sharded data transmission and migration. The ZKP system is used to provide secure data transfer by sharing proof of data authenticity with verifiers at destination cloud services without revealing the actual data during data migration.

Table 9. Comparative Analyses of ZKP approaches in Blockchain Systems.

Article	Application Type	Privacy Issue	Algorithms/ Types	Algo. Comparisons	Proof Size	Generation Time	Verification Time	Execution Cost
this paper	feedback system	project participants linkability	zk-SNARK Merkle, zk-SNARK range, Paillier	1	1	0	0	1
[67]	Auctioning system	bid information confidentiality	Pedersen commitment scheme	0	0	0	0	1
[66]	Identity authentication	selective information sharing in KYC	range proofs, set membership	1	0	0	0	0
[68]	Drug deliver Supply chain	product compliance verification	zk-SNARK	1	0	0	1	1
[69]	IoT data transmission	integrity of firmware execution	zk-SNARK	1	0	1	1	0
[70]	Data migration in cloud	data authenticity	zk-SNARK	0	0	1	0	0

shows the comparison of the application of different ZKP approaches in blockchain systems to examine the application types, privacy problems addressed, selected ZKP algorithms, and performance evaluation approaches adopted. The result shows that, similar to this current paper, zk-SNARKs are adopted in the following works [68,69,70] to verify product compliance, ensure the integrity of IoT data transmission logic, and ensure the authenticity of data during data retrieval. Other ZKP algorithms used in these works include Paillier cryptography for homomorphic calculation of rating and the Pedersen commitment scheme for range verification of bids. Some of these works [67,68,69] compared the performances of different ZKP algorithms and solutions similar to this current paper. All the papers adopted at least one evaluation approach to examine the performance of the implemented system, except the paper [67]. The performance evaluation approaches check the proof size generated, the proof generation time, the proof verification time, and the on-chain execution costs of the ZKP system.

7.4. Attack Models on the Proof-Based Feedback System

This part of the paper discusses various attack models that can affect the ZKP system developed in this paper for privacy-preserving feedback rating. Sybil and collusion attacks are common to collaboration systems [12,71]. There are also specific attacks for zk-SNARKs, like fake proof generation and homomorphic encryption attacks.

-

Sybil attacks: This type of attack involves the generation of multiple fake identities to overwhelm the system. The scenario-based evaluation earlier in Section 6.1 shows that the proof-based system can prevent fake membership proof generation. However, the system is susceptible to resource exhaustion attacks. An attacker can submit several proofs of membership and on-time rating submissions with several identities they control. The goal is not that the submitted incorrect proofs are verified, but rather to overwhelm the feedback system with verification requests. This is because the homomorphic rating calculator first verifies the submitted proofs and includes ratings submitted with valid proofs. However, since the prover bears the verification costs, an attacker needs huge financial resources to succeed with the attack and take out the feedback system with multiple requests.

-

Collusion attacks: The proof-based feedback system developed in this paper does not generally prevent collusion attacks since the goal of the system is to limit linkability with parties outside the project collaboration. However, the collaborating parties themselves, therefore, they can collude to manipulate the feedback system. Through off-chain information sharing, a group of actors can collude to generate high or low ratings for the project or specific project partners.

-

zk-SNARKs fake proof attacks: Trusted setup is an important requirement for proof generation in several zk-SNARKs libraries like GROTh16 used in this work. If the trusted entity is compromised, fake proofs can be generated. With a fake proof of membership generated, an attacker can submit a rating on time, and such a rating will be used in calculating the final rating score for the project or the project partner. This type of attack is similar to a malicious insider attack that affects several software systems. Multi-party computation has been proposed to replace the trusted party setup in SNARKs [72]. Instead of relying on a single trusted party, the proof setup requires the distribution of the proof generation setup process among multiple parties to prevent fraudulent proof generation.

-

Homomorphic encryption-specific attack: The on-chain encrypted addition of ratings, the off-chain decryption of ratings, and the derivation of the final rating score require that all the collaborating parties use the same key to encrypt their ratings before submitting on-chain. Hence, an attacker, without knowing the actual rating value, can infer high ratings and low ratings submitted; therefore, can deduce patterns and relationships between the collaborating parties. One option to limit this type of linkability is to introduce a unique cryptographic salting to the encrypted ratings before they are submitted, and the homomorphic smart contract can remove these saltings before adding the ratings.

8. Conclusions

The goal of this paper is to understand linkability problems in blockchain-based collaboration systems and provide suitable proof-based solutions to address the linkability problems to achieve a privacy-aware design of collaborative systems. Hence, the paper seeks to answer the research question of how to design and implement privacy-aware collaborations on the blockchain through the integration of proof-based solutions to address linkability problems. To achieve this goal, the paper analyzed relevant literature to identify types of linkability problems and used it as a basis to assess blockchain-based collaboration systems for linkability problems. The result shows that the common linkability problems include project-specific, location- and time-specific, and transaction/user type linkabilities. The least common are feedback and reputation-specific linkabilities. The paper also formalized these linkability problems, and the resulting groups include set problems, transaction obfuscation, homomorphic calculations, and range problems. Furthermore, the paper demonstrated proof-based solutions to these linkability problems by using zk-SNARK algorithms and Paillier cryptography to design and implement a PoC of privacy-preserving feedback mechanisms in collaboration systems. Using scenario-based evaluation, the result shows that the demonstrated system ensures that only valid ratings submitted on time by valid projects are used in final rating calculations without revealing the identities of project members when the ratings are submitted and the actual ratings submitted. The result from this work can be extended to other use cases, especially in digital product passports and sustainability claims verification. Algorithms applied in this work, such as membership verifications and range proofs, can be applied in developing privacy-preserving mechanism for verifying material compositions and products’ CO₂ emission levels.

A potential limitation of this work is the risk of generalization, as there could be other types of linkability problems that were not identified. Secondly, the algorithms used for the implementation of the PoC are not optimized for high performance. There is also a limitation on the lack of a production-ready environment for generating proofs through Circom templates, as the work experiments carried out in this paper rely on test environments such as REMIX IDE. One of the potential future works from this research is to evaluate the performance of different ZKP algorithms in designing and implementing a privacy-aware feedback mechanism. In addition, future work will also explore optimization approaches to improve the performance of the ZKP system developed in this work, and use cases that involve interaction patterns and graph-structured linkability problems will be examined.