Abstract
Most blockchain and smart contract platforms store transactions publicly on the ledger. User accounts in these systems rely on public keys to prevent direct identification of the parties. However, various de-anonymization techniques have been used to disclose users’ data, highlighting the weakness of this approach. As a result, the implementation of certain decentralized applications is challenging, especially those involving personal and financial data. In this context, several solutions have been proposed to provide privacy for users of blockchain and smart contract applications. Nonetheless, implementing these solutions is not trivial and introduces additional challenges related to performance, transaction costs, and application complexity. This article describes the practical implementation of Miles2Coins, a blockchain application for buying and selling tokenized airline miles, and details the intricate process of integrating it with Anonymous Zether, a solution designed to provide privacy and anonymity for the parties involved in these transactions. The challenges faced during this integration are explored, revealing key limitations and highlighting the ongoing need for improved privacy approaches in this scenario.
Keywords
Introduction
In 2008, the Bitcoin whitepaper 1 introduced a novel distributed ledger technology (DLT) known as blockchain, enabling multiple parties to conduct transactions in the newly established cryptocurrency without relying on a trusted intermediary. Since its emergence, blockchain technology has gained widespread popularity and, with the advent of Ethereum,2,3 evolved to support smart contracts—self-executing programs that run on the blockchain and enforce predefined rules without intermediaries. 4 This advancement enables sophisticated algorithms to be executed across a multitude of applications beyond payment transactions. Such applications include auctions, crowdfunding platforms, electronic voting, sharing patient medical records, and integrating Internet of Things devices.4–6
In Bitcoin, Ethereum, and other public blockchain platforms, transactions are recorded transparently on the ledger. While this transparency facilitates the auditing of transaction data by any node connected to the network, it also raises significant privacy concerns. For instance, in Bitcoin’s design, user privacy should be ensured by associating parties solely with their public keys, which should be renewed after each transaction. 1 However, various de-anonymization and transaction linking techniques have exposed the limitations of this approach.7–9 Additionally, keeping transaction data public makes it possible to infer information about the parties involved. As a result, there is a notable challenge in implementing applications where privacy is a fundamental concern, such as:
Electronic medical records sharing: Patient medical records and related data (tests, images, and documents) can be stored on a blockchain, but these personal data must be accessible only to authorized individuals. This is unfeasible on most blockchains without additional privacy layers and access control mechanisms.
10
Sealed-bid auctions: Since each bid should remain confidential, publicly recording bid-submission transactions undermines the auction process by allowing participants to see other bids and adjust their own to win with a minimal margin.
11
Decentralized finance (DeFi): In decentralized financial applications, such as peer-to-peer lending platforms and decentralized exchanges (DEXs), digital assets and cryptocurrencies are traded without intermediaries.
12
Ensuring transaction privacy is essential to maintain the confidentiality of participants’ balances and trades. Central Bank Digital Currencies (CBDCs): Central banks worldwide are examining, testing, or planning digital currencies, with many considering blockchain as the underlying technology.13,14 A notable example is Drex, Brazil’s forthcoming digital currency, under development by the country’s monetary authority.
15
Drex will use a permissioned blockchain to issue the CBDC and facilitate tokenized asset transactions. In this scenario, privacy is critical: citizens and companies must not view each other’s transactions, and financial institutions cannot see the CBDC or token balances of other institutions.
In response to Bitcoin’s privacy shortcomings, new cryptocurrencies such as Zerocash 16 (now Zcash 17 ) and Monero 18 were developed with a focus on transaction confidentiality. However, these solutions primarily address the privacy of cryptocurrency transactions and are not designed for broader smart contract-based applications. Meanwhile, other DLT platforms like Hyperledger Fabric 19 and R3 Corda, 20 offer enhanced security and privacy features but adhere to permissioned or private DLT models. 21
Despite these advancements, there remains a clear need for efficient and comprehensive privacy solutions that can be applied across various use cases and support smart contracts on both permissioned and public blockchains. To address this gap, numerous blockchain privacy solutions have been proposed, employing diverse techniques, including zero-knowledge proofs (ZKPs),22–30 homomorphic encryption (HE),11,31–35 delegation to trusted-execution environments (TEEs)36–40 or trusted third parties,5,41 and combinations of these paradigms. Additional strategies, such as secure multiparty computation (SMPC), mixing, and ring signatures, may further enhance privacy.8,18,42,43 Existing approaches provide varying levels of privacy, ranging from concealing transaction values to ensuring full anonymity and confidentiality of the computation itself. 44
Privacy solutions also vary in their supported transaction model—UTXO (Unspent Transaction Output) versus Account-Based. In the UTXO model, used by Bitcoin, each transaction consumes specific outputs from previous transactions and produces new outputs, allowing ownership tracking of cryptocurrencies or tokens. By contrast, the account-based model, employed by Ethereum, associates balances directly with user accounts and updates those balances via transactions. While the account-based method is often more efficient for complex smart contracts—since it eliminates the need to track multiple UTXOs—it may be less optimal for simpler use cases.45,46
Another key challenge lies in the impact on performance and transaction costs when integrating a privacy solution into a blockchain-based application. Some solutions perform operations off-chain (i.e. private data is processed by the user or specialized entities outside the blockchain network).5,22–30,35–41 While this approach lowers the computational burden on the network, it may also reduce transparency and increase complexity. Conversely, solutions that execute most operations on-chain11,31–34 improve transparency but often suffer from reduced performance and higher transaction costs, since each node must execute complex cryptographic operations to ensure privacy. 44
In this context, the objective of this work is to explore the main challenges of enhancing blockchain privacy through a case study involving the implementation of a privacy solution for a decentralized application on a local Ethereum test network. The application developed for this study, named Miles2Coins, enables users to buy and sell tokenized airline miles (MilesToken) using a fictitious stablecoin (SampleCoin). To ensure secure transactions, the platform must support delivery-versus-payment (DvP) transactions, guaranteeing atomic execution and ensuring that each party fulfills its obligation for the trade to succeed. Privacy in this scenario is crucial, as users typically seek to protect their transaction details and keep their balances undisclosed.
To address these privacy requirements in Miles2Coins, 21 privacy solutions were evaluated. After a thorough selection process described in Section 4.2, Anonymous Zether 32 was chosen primarily for its ability to ensure both transaction confidentiality and user anonymity. This work details the complex task of integrating Anonymous Zether into the original Miles2Coins application.
This study demonstrates the added complexity of designing privacy-focused, smart contract-based blockchain applications. The findings showcase the features and limitations of the integrated solution, while also examining the advantages and drawbacks of adding a privacy layer in this setting. The experimental results reveal that incorporating privacy into blockchain applications can significantly increase transaction costs and impact performance, mainly due to the higher demand for computational resources such as CPU and RAM. Although privacy remains a major and ongoing topic of debate in blockchain, this work contributes to the field by providing both a conceptual analysis and a practical experiment that illustrates the challenges of enhancing privacy in decentralized, blockchain-based applications.
The remaining part of this article is structured as follows. Section 2 reviews the related work on blockchain privacy. Section 3 explores the key techniques and solutions for enhancing privacy in blockchain applications. Section 4 presents the case study conducted in this work, detailing the implementation of Miles2Coins and the selection of Anonymous Zether as the privacy solution for integration. Section 5 describes the integration process, while Section 6 reports the experimental results and highlights the main challenges in improving blockchain privacy. Section 7 discusses the feasibility of achieving end-to-end privacy on public blockchains. Finally, Section 8 summarizes the findings and conclusions of this study.
Related work
Privacy issues in blockchain systems are a widely researched and debated topic. This section examines key research contributions in the field.
Bernal Bernabe et al. 8 present a systematic review of privacy-preserving approaches for blockchain, analyzing key challenges, cryptographic techniques, and future research directions. Their study evaluates existing methods and discusses their applications in domains such as e-Government, e-Health, and cryptocurrencies. The authors highlight that current blockchain platforms fail to meet minimal privacy requirements, compromising user rights and hindering compliance with data protection regulations such as General Data Protection Regulation (GDPR). 47 The paper emphasizes the need for future research to balance privacy with regulatory compliance while addressing usability, scalability, and interoperability.
Wang et al. 48 conduct a systematic mapping study that identifies challenges, advances, and gaps in blockchain and smart contract security and privacy. The authors point out that future work on blockchain privacy should focus on combining cryptographic techniques, such as ZKPs and HE, with secure hardware enclaves.
Almashaqbeh and Solomon 44 provide a systematization of knowledge on blockchain and smart contract privacy challenges, outlining common techniques adopted by various privacy solutions. Their paper carefully examines ten approaches, providing an in-depth comparison of their functionalities and limitations. Additionally, the article highlights key challenges faced by existing privacy solutions, including concurrency issues, transaction costs, and trust assumptions. Finally, the authors propose future research directions, including optimizing ZKP and HE algorithms for greater efficiency.
Qi et al. 49 present a comprehensive survey on privacy-preserving smart contract (PPSC) schemes, categorizing them into two main approaches: cryptographic-based methods, which utilize ZKPs, SMPC, and HE; and TEE-based methods, which rely on hardware-secured enclaves. The authors analyze 19 solutions, emphasizing challenges such as the expressiveness and efficiency limitations of ZKP-based approaches and the strong dependency of TEE-based solutions on Intel Software Guard Extensions (SGX). 50 Additionally, the paper explores future research directions, including improving the efficiency of ZKP-based schemes by outsourcing proof generation to TEE servers and reducing reliance on a single TEE provider by integrating heterogeneous TEE implementations into blockchain systems.
While the studies above provide a theoretical analysis of different approaches to achieving privacy in blockchain systems, other research focuses on developing privacy-preserving blockchain applications for specific use cases by directly employing encryption, hashes, and other techniques.
Unterweger et al. 51 present the implementation of a PPSC in the energy sector, allowing customers to select optimal tariffs based on their energy consumption. To maintain privacy, the solution relies on hashes and other cryptographic methods. However, the study concludes that high gas costs render such a smart contract unfeasible for deployment on Ethereum.
Zhang et al. 52 propose a privacy-preserving voting protocol on blockchain. The authors introduce a protocol that ensures voter privacy while maintaining verifiability and resistance to fraud. The proposed solution leverages HE and distributed tallying to eliminate the need for trusted authorities. The paper discusses challenges such as synchronization issues and dishonest peer detection, outlining future research directions, including improving scalability and further security analysis of the protocol.
Li et al. 53 propose addressing blockchain’s privacy and scalability issues by splitting a smart contract into two components: one executed off-chain, handling computationally expensive operations and sensitive data, and another on-chain, involving lightweight computations and public data. The paper defines a dispute resolution protocol that allows for on-chain execution of a verified instance of the off-chain contract when necessary. However, this approach introduces implementation complexity, and in cases of dishonest off-chain computation, the performance overhead and transaction costs may render dispute resolution impractical.
Previous research primarily focuses on two areas: theoretical surveys that analyze privacy challenges, techniques, and solutions, as well as practical implementations of privacy mechanisms in specific use cases. However, the process of selecting and integrating comprehensive privacy solutions into existing applications remains underexplored, with limited literature addressing the challenges involved. This study aims to bridge this gap by providing both a conceptual analysis of privacy techniques and a practical evaluation. Using Miles2Coins as a case study, it demonstrates the privacy enhancements achieved and the challenges encountered during integration. Therefore, this work provides a broader perspective on blockchain privacy, highlighting key complexities, limitations, and potential barriers developers may face when adopting privacy-preserving approaches in practice.
Enhancing blockchain privacy
As blockchain technology has evolved, smart contracts have enabled the emergence of numerous decentralized applications across various domains. With the rise of use cases involving sensitive information, concerns about user privacy have intensified, particularly in light of regulatory frameworks such as the GDPR in the European Union 47 and the California Consumer Privacy Act (CCPA) in the United States. 54
Privacy-enhancing techniques
The inherent privacy challenges of blockchain have led to the development of various strategies aimed at enhancing user privacy. Common approaches include delegating private computations to trusted entities or employing cryptographic techniques—primarily ZKPs and HE—to safeguard sensitive data. 44 These strategies can also be combined with complementary methods such as secure multi-party computation (SMPC), ring signatures, and mixing to further strengthen privacy. 43 This section explores each of these techniques in detail.
Delegation of computation
One approach to enhancing privacy involves delegating the computation of sensitive data to trusted entities. This can be achieved through TEEs or by relying on designated trusted parties.
Delegation to TEEs: A TEE consists of an isolated area within a processor, known as a “secure enclave,” designed to perform operations securely and independently. TEEs provide hardware-level security, ensuring the confidentiality and integrity of operations. Additionally, TEEs can generate attestations—cryptographic proofs that verify the correctness of the computations performed within the enclave.
55
Intel SGX
50
is the most widely used TEE technology, but alternatives like AMD Secure Encrypted Virtualization (SEV)
56
and ARM TrustZone
57
are also available. TEEs can be leveraged to process transactions involving sensitive data while guaranteeing that only encrypted and public information is stored on-chain. Delegation to Trusted Third Parties: In this approach, sensitive computations are outsourced to trusted entities, commonly referred to as “managers.” These managers act as special nodes that process confidential data off-chain while ensuring the correctness of computations.
44
Cryptographic methods are at the core of many privacy-preserving solutions. Two of the most widely used techniques are ZKPs and HE, which can be applied independently or in combination.
ZKPs: ZKPs are cryptographic protocols that allow a prover to demonstrate to a verifier that a statement about specific data is true without revealing any additional information.
58
For example, ZKPs can confirm that a financial transaction involves the transfer of a certain asset without disclosing the sender, recipient, or transaction amount, while still ensuring its validity. HE: HE allows computations to be performed directly on encrypted data, producing an encrypted result that, when decrypted, matches the result of the same operations performed on the original data. There are three levels of HE: additive, multiplicative, and fully homomorphic. Additive HE supports addition and subtraction operations on encrypted data. Multiplicative HE enables multiplication and division on encrypted data. Lastly, fully HE (FHE) allows a full range of arithmetic operations on encrypted data, maintaining privacy throughout the computational process.
44
In addition to delegation and cryptographic techniques, privacy in blockchain systems can be enhanced through complementary methods, including SMPC, which enables collaborative computations on private data without revealing individual inputs; ring signatures, which allow a user to sign transactions anonymously within a group; and mixing, which obscures transaction links by combining or redistributing funds.8,18,42,43
Privacy solutions
This study included a comprehensive analysis of various privacy strategies for blockchain applications. Twenty one solutions were selected for conceptual evaluation, meaning they were analyzed based on their respective articles without practical implementation. These solutions were categorized according to the primary techniques they employ:
Delegation-based solutions ZKP-based solutions: These solutions utilize ZKPs to keep transaction data confidential while ensuring verifiability. Eight solutions were associated to this category: zkay,24,28 Zapper,
29
Zexe
25
, VeriZexe,
30
Kachina,
27
zkHawk,
22
Eagle,
23
and RPSC.
26
ZKP and HE-based solutions: These solutions combine ZKPs with HE to ensure confidentiality while enabling computations on encrypted data, such as account balances. Six solutions were mapped in this category: Zether,
11
Anonymous Zether,
32
PriDe CT,
33
Zeestar,
35
SmartFHE,
34
and fhEVM.
31
The complementary approaches described in Section 3.1.3 contribute to privacy enhancement but are rarely used in isolation as primary techniques. Therefore, this study does not define a separate category for them.
Although a thorough theoretical evaluation of multiple privacy solutions was conducted, the practical analysis focuses on a single solution, chosen through the process outlined in Section 4.2. Nevertheless, highlighting the key aspects, advantages, and trade-offs of each category provides valuable insights.
Delegation-based solutions
These solutions offer strong privacy features with generally low performance overhead and transaction costs, as they typically avoid computationally expensive techniques like ZKPs. However, their main drawback is their reliance on trust in third parties. Hawk 5 specifies a protocol in which the contract is split into public and private parts, with the latter being processed off-chain by a manager. As a result, this solution requires trust in the manager to prevent information leakage. Arbitrum 41 improves performance and resilience by using multiple managers per application, but its privacy level can be considered lower, as transaction details remain visible to all managers.
Solutions leveraging TEEs provide enhanced privacy, performance, and scalability by conducting most computations off-chain on secure enclaves and avoiding expensive techniques like ZKP generation. While TEE-based systems such as ShadowEth, 40 Ekiden, 36 Secret Network, 39 POSE 37 and EtherCloak 38 are designed to be agnostic to specific TEE implementations, they remain fully dependent on the security of the TEE and its manufacturer. This dependency introduces inherent risks, as vulnerabilities in the TEE can compromise the entire system. For instance, secret network faced a potential exposure of its consensus seed due to an SGX vulnerability, which, if exploited, could have exposed all transactions, undermining its privacy guarantees.59–62
ZKP-based solutions
Using ZKPs has a clear advantage in terms of privacy, as it does not rely on trusted parties while enabling operations to be verifiable without exposing confidential data on the blockchain. However, these solutions often require a trusted setup for cryptographic parameters, which must be carefully executed to prevent potential data leaks. This necessity can be a major drawback, as seen in zkay,24,28 Zexe, 25 and RPSC, 26 which require a dedicated setup for each application. Zapper 29 and VeriZexe 30 have improved upon this by utilizing a universal trusted setup, yet the computational burden on users for generating ZKPs remains a significant challenge across all ZKP-based solutions. Additionally, functional constraints—such as the inability to support loops involving private data or complex control structures in zkay and Zapper—further restrict their applicability in more advanced use cases. Some newer ZKP-based solutions explore novel approaches, such as combining ZKPs with SMPC in zkHawk 22 and Eagle 23 or introducing state oracles for private state updates in Kachina. 27 Nevertheless, these solutions remain largely theoretical, as no practical implementations were provided to assess their real-world performance and feasibility.
ZKP and HE-based solutions
The combination of ZKPs and HE offers a compelling balance between privacy and efficiency by enabling computations on encrypted data while preserving transaction confidentiality. Zeestar 35 and Zether 11 utilize ZKPs to conceal transaction values and employ additive HE to operate on encrypted balances efficiently. However, these on-chain operations lead to increased performance overhead and transaction costs. Anonymous Zether 32 extends Zether by introducing anonymity through a ring signature scheme, but this improvement requires locking multiple accounts during transactions, which introduces additional complexity and computational overhead. PriDe CT 33 mitigates some of these issues by batching transactions and reducing the number of locked accounts, yet scalability remains a concern.
Other solutions, such as SmartFHE, 34 and fhEVM, 31 leverage FHE to enable more expressive and complex privacy-preserving applications. SmartFHE shifts computational effort to miners, reducing user-side overhead, but this comes at the cost of substantial delays in ZKP verification. fhEVM, in contrast, integrates FHE directly into Ethereum’s EVM, allowing developers to work with encrypted data using standard Solidity syntax. Despite these improvements, fhEVM relies on threshold decryption, requiring a group of validators to collaborate, and lacks detailed performance evaluations, making it difficult to determine its practical feasibility. While HE-based solutions provide advantages by enabling operations directly on encrypted balances, the persistent reliance on ZKPs results in high computational overhead and significant on-chain costs, which remain key challenges. 44
Case study: Privacy enhancement in a DeFi application
Many applications require strong transaction confidentiality and user privacy, especially in the DeFi ecosystem. On a DEX, which facilitates peer-to-peer trading of tokens and cryptocurrencies without intermediaries, transactions should remain private to prevent exposing the assets being traded and their respective amounts. A fundamental aspect of digital asset exchange transactions is the concept of DvP. An application that supports DvP transactions ensures that parties in an exchange operation only transfer their respective assets if and only if the other side fulfills its part of the agreement, thus ensuring transaction security. 63
Given the importance of privacy in DeFi, this work envisions implementing Miles2Coins, a sample application for trading airline mile tokens via DvP transactions, while integrating an existing solution to enhance user privacy. The study evaluates not only the level of privacy achieved but also the challenges encountered during the integration process, including increased complexity and the impact on performance and transaction costs. By examining these factors, this work provides insights into both the improvements gained and the limitations posed by incorporating privacy solutions into blockchain-based applications.
Rationale for this approach
Rather than examining a well-established DeFi system, such as a decentralized exchange (e.g. Uniswap 64 or curve 65 ), this study implements the sample Miles2Coins application. This approach offers a more focused environment where privacy requirements can be studied without excessive engineering overhead. If popular DeFi platforms were used, it would be difficult to concentrate specifically on privacy concerns, since those systems usually involve multiple smart contracts, front-end components, and specialized logic. Since DeFi applications often handle personal and financial information, the privacy requirements in this scenario are similar, making this analysis valuable for other DeFi use cases.
Likewise, implementing advanced privacy features from scratch—for instance, using ZKPs, HE, or TEEs—would require significant cryptographic expertise and could tightly couple the resulting solution to a single use case. By adopting an existing privacy solution instead, this work maintains a modular design that, ideally, can be extended to other blockchain applications. This perspective is closer to a real-world scenario, in which a developer seeks to meet privacy requirements in a DeFi application without delving into low-level cryptographic implementations, thereby leveraging an existing privacy solution.
Miles2Coins
Miles2Coins is a platform for buying and selling airline miles (MilesToken) via DvP transactions, using a fictitious stablecoin (SampleCoin) as the exchange currency. The application is implemented on a local Ethereum test network and consists of a smart contract and a JavaScript client application to interact with it. Miles2Coins provides the following core functionalities:
Offer registration (placeOffer function): Allows users to create trade offers, which can be: Purchase offers: Users specify the amount of MilesTokens they want to buy and the amount of SampleCoins they are willing to pay. When creating a purchase offer, the user approves the Miles2Coins contract to transfer the specified SampleCoins on their behalf if the offer is later accepted. Sale offers: Users indicate the quantity of MilesTokens they wish to sell and the price per mile in SampleCoins. When creating a sale offer, the user approves the Miles2Coins contract to transfer the specified MilesTokens if the offer is accepted. Offer listing (listOffers function): Enables users to retrieve a list of the active trade offers to find the most suitable one. Offer acceptance (acceptOffer function): Allows users to accept an existing offer, triggering the following steps: The user provides the approval for the Miles2Coins contract to transfer their MilesTokens (when accepting a purchase offer) or SampleCoins (when accepting a sale offer). The contract verifies that both users have sufficient token balances. If the balances are adequate, the contract executes the atomic transfer of MilesTokens from the seller to the buyer and SampleCoins from the buyer to the seller. If any step fails, the transaction is reverted. The offer is marked as inactive upon successful completion of the transaction.
The sample digital assets created specifically for this application are MilesToken, an ERC-1155 token 66 representing the airline miles, and SampleCoin, an ERC-20 token 67 representing the fictitious stablecoin to be used as the exchange currency. Thus, in addition to the main Miles2Coins smart contract, two other contracts were created to manage these tokens.
Key terminology and definitions.
Key terminology and definitions.
Miles2Coins privacy and usability requirements
In its original design, Miles2Coins does not offer privacy features beyond those inherently provided by the underlying blockchain. This means that users are responsible for protecting their pseudonyms and should ideally generate new key pairs for each transaction. Furthermore, in this setup, all transactions conducted on the platform are publicly recorded on the blockchain, exposing details such as traded amounts, the Ethereum addresses of the involved accounts, and token balances. This transparency enables transaction linking and deanonymization techniques, compromising user privacy.
Given this scenario, it is essential to identify the specific privacy and usability requirements for Miles2Coins, which will serve as the foundation for selecting the most suitable privacy solution for integration. The defined requirements are as follows:
Confidentiality and anonymity: Since the application handles financial transactions, ensuring the confidentiality of transactional data is crucial. Additionally, preserving the anonymity of the involved parties is highly desirable to minimize exposure risks. Full decentralization and minimal trust assumptions: Solutions that rely on trusted third parties are not recommended, as the goal is to maintain a fully decentralized application that is simple and free from external dependencies that could compromise its security or functionality.59,61 Compatibility with Ethereum and account-based model: To ensure expressiveness and applicability, the application should be compatible with Ethereum, the leading smart contract platform. The account-based model should be supported, as it aligns with Ethereum’s architecture and facilitates future expansion to more complex use cases. Adopting the UTXO model could limit this compatibility and flexibility.45,46 Balanced performance and transaction costs: It is desirable that the solution does not impose excessive overhead on the client side, favoring optimized performance. Although transaction costs are a relevant factor, they are not expected to be a barrier to adoption. These costs could potentially be incorporated as a service fee passed on to the users of the platform.
With the privacy and usability requirements of Miles2Coins clearly defined, the next step is selecting the most suitable option for integration from the 21 studied privacy solutions. This process is not trivial, as it must consider not only Miles2Coins’ identified requirements but also the features and limitations of the available solutions, as well as the existence of repositories with documentation and source code. The selection process is detailed below.
Eliminating delegation-based solutions: To meet Requirement 2 (full decentralization and minimal trust assumptions), solutions that delegate the computation of private data to third parties, such as managers or TEEs, were excluded. These architectures inherently require trust in external entities, making it difficult to satisfy Requirement 2. Moreover, the majority of the papers presenting these solutions did not provide links to repositories with source code and documentation, further hindering practical evaluation. Finally, the need for specific environments, such as Intel SGX,
50
imposes further constraints on their feasibility in a test environment. As a result, Hawk,
5
Arbitrum,
41
Shadoweth,
40
Ekiden,
36
Secret Network,
39
POSE,
37
and EtherCloak
38
were discarded. Ensuring Ethereum compatibility: To fulfill Requirement 3, solutions must be compatible with Ethereum, supporting the account-based model. Only six solutions satisfy these criteria: zkay,24,28 RPSC,
26
Zether,
11
Anonymous Zether,
32
PriDe CT,
33
and Zeestar.
35
The remaining solutions (Zapper,
29
Zexe,
25
VeriZexe,
30
Kachina,
27
zkHawk,
22
SmartFHE,
34
and fhEVM
31
) were excluded as they either require a custom architecture, operate on alternative blockchains, or adopt the UTXO model. Checking for public repositories: Among the six remaining solutions, only zkay, Anonymous Zether, and Zeestar have publicly available repositories73–75—an essential factor for enabling practical evaluation. Consequently, the other solutions (RPSC, Zether, and PriDe CT) were eliminated. Ensuring stronger privacy guarantees: Among the remaining solutions, zkay and Zeestar have two drawbacks: they require a trusted setup for each application, which hinders full compliance with Requirement 2, and they do not provide anonymity, only partially fulfilling Requirement 1. Therefore, they were eliminated. Based on the evaluated criteria, Anonymous Zether is the best fit for Requirement 1, as it ensures transaction confidentiality, balance privacy, and anonymity for the involved parties while minimizing trust assumptions.
Since Anonymous Zether relies on ZKPs and HE, both computationally intensive cryptographic techniques, its integration is expected to significantly impact the application’s overall performance. However, given that Miles2Coins would operate on Ethereum, where transaction throughput is relatively low, 76 and considering that users are unlikely to execute frequent transactions within a short time frame, performance is not a primary concern in this case. The main challenge with using Anonymous Zether lies in transaction costs, as its required on-chain operations—particularly ZKP verifications and HE computations—are highly resource-intensive, leading to high gas fees.32,44 Therefore, evaluating the transaction costs in the final implementation is crucial to determine whether the solution is viable on Ethereum or if an alternative blockchain with lower transaction fees would be more suitable.
Another limitation of Anonymous Zether is that its functionality is restricted to a limited class of private smart contracts, such as token exchanges, auctions, payment channels, voting, and consensus mechanisms. 32 This limitation arises mainly due to its reliance on additive homomorphic encryption, which may not support more complex decentralized applications. Nonetheless, since Miles2Coins primarily involves token transactions, this constraint should not obstruct the adoption of Anonymous Zether for enhancing privacy in this case.
It is important to note that the selection of the privacy solution was based on a theoretical evaluation, focusing on the technical analysis of the research papers in which the solutions were proposed, rather than their practical implementation. This approach aligns with the perspective of a blockchain application developer, whose primary goal is to implement a specific set of functionalities to address a particular use case, achieving an adequate level of privacy without dedicating excessive time or resources to meet privacy requirements. Consequently, a practical evaluation to assess each solution’s functionalities, limitations, performance impact, and transaction costs falls beyond the scope of this case study. This practical analysis is conducted solely for Anonymous Zether, the selected solution.
Bünz et al. 11 introduce Zether, which combines ZKPs with additive homomorphic ElGamal encryption, 77 providing confidentiality not only for transactions but also for the balances of the involved parties. Zether adopts an account-based model that allows updating account balances without revealing them. In the original paper, the authors mention the potential for a version of Zether supporting the anonymity of involved parties but leave this implementation for future work.
Diamond 32 proposes Anonymous Zether, which enhances Zether by enabling the sender of a transaction to use a set of accounts (referred to as the “anonymity set”) to obscure both the sender’s and receiver’s identities. To achieve this, the author develops a family of extensions to the “One-out-of-many proofs” ring signature technique, 78 resulting in an efficient implementation of Zether with anonymity for the involved parties. The artifacts and code for this solution are open-sourced and released by the author. Currently, the Anonymous Zether repository remains public but is maintained by Kaleido. 75
Practically, Anonymous Zether consists of one or more Zether tokens (ZTH), managed by Zether smart contracts (ZSCs) deployed on the blockchain. Users can convert cryptocurrencies or other tokens into ZTH and conduct transactions with privacy and anonymity using these tokens. In a 2023 study, Diamond 79 presents a settlement contract designed to facilitate DvP transactions between two Zether tokens, each representing a specific asset, ensuring atomic and private swaps between parties. However, the paper does not provide an implementation of this settlement contract.
A recent initiative that tested Anonymous Zether is Drex, 15 also known as Digital Real, the upcoming Brazilian CBDC, which will be implemented through smart contracts running on a permissioned blockchain. In the pilot phase of the project, developers evaluated various privacy solutions, including Anonymous Zether. Consequently, with support from the researchers who proposed Zether, a settlement contract was developed to enable atomic swaps between Zether tokens representing the CBDC and other tokens.
In this work, since Anonymous Zether is employed to enhance user privacy in DvP transactions, artifacts from the following projects are used:
Anonymous Zether (hardhat branch) from Kaleido,
75
which includes the solution’s main smart contracts and other related artifacts. Anonymous Zether client (real-digital branch) from Kaleido,
80
featuring the implementation of a JavaScript client to interact with Zether contracts. Central Bank of Brazil’s Drex pilot project,
81
which contains the settlement contract for DvP transactions using Anonymous Zether (DvpZSC.sol).
Miles2Coins and Anonymous Zether integration
This section describes the integration of Miles2Coins with Anonymous Zether to enhance privacy. The primary goal is to ensure confidentiality by concealing transaction details and the balances of MilesToken and SampleCoin, while also preserving the anonymity of the involved parties.
Experimental setup
Miles2Coins consists of one smart contract for the main application, written in Solidity (Miles2Coins.sol), and a set of scripts, written in JavaScript, that act as the client application, enabling interaction with the main smart contract. The airline miles token and the stablecoin are managed by MilesToken.sol and SampleCoin.sol, respectively, which adhere to the ERC-1155 66 and ERC-20 67 standards.
Anonymous Zether comprises a set of smart contracts, including ZSCs for token representation and the settlement contract (DvpZSC.sol), along with several auxiliary contracts. Additionally, it includes a client application—also written in JavaScript—responsible for performing cryptographic operations, such as generating key pairs and ZKPs, and for interacting with the Zether contracts running on the blockchain.
The experimental environment was set up locally on a Windows 11 machine using Node.js 82 as the JavaScript runtime environment, with Hardhat Network 83 configured to run a local Ethereum blockchain where the application and token contracts were deployed. Figure 1 illustrates this environment.
Experimental setup.
Apache JMeter 84 was also employed during performance testing, as explained in Section 6.2. During each test, CPU and memory usage were measured, and transaction times and gas costs were recorded. Each scenario was repeated 10 times, and the average values were reported.
The hardware specifications consist of an Intel Core i7-10750H CPU with six cores (12 threads) running at 2.60 GHz, 16 GB of RAM, and a 512 GB PCIe SSD.
The source code and documentation, including installation steps, software versions, and additional information, are available in Daniel Almendra. 85
A key premise of this project is to avoid making significant structural changes to Miles2Coins and Anonymous Zether. The goal is to integrate the privacy solution without deeply altering the application’s functions or extensively adapting the Anonymous Zether contracts and scripts to optimize privacy or performance. While this approach may lead to a less-than-ideal final solution, it is crucial for assessing the applicability of the privacy solution in its current form, without enhancements or major adaptations. Additionally, it prevents tight coupling between the application and the privacy solution, ensuring that the final application remains flexible and not overly dependent on a specific privacy architecture.
As described in Section 4.3, Anonymous Zether is designed to enable private token transfers and swaps but is generally unsuitable for enhancing the confidentiality of operations that do not involve token transfers. Therefore, integrating Anonymous Zether with the placeOffer and listOffers operations—responsible for registering and listing offers—is not practical. Instead, integration is relevant only for the final part of the acceptOffer operation, where the actual token transfer takes place.
Consequently, the resulting application retains the original Miles2Coins structure while incorporating privacy enhancements, provided by Anonymous Zether, exclusively for the DvP transaction between the user who places the offer and the one who accepts it. However, executing this final transaction through Anonymous Zether presents additional challenges. To better understand these issues, it is essential to first examine how the DvP transaction is processed within this solution.
Anonymous Zether DvP transaction
For users to execute a DvP transaction with Anonymous Zether, they must utilize the Anonymous Zether client—which, in a production implementation, could be integrated with the Miles2Coins client—to perform the following actions:
Create an account on Zether (newAccount function), which basically generates an Ethereum wallet with its associated address and key pair, and a shielded-account, consisting of an ElGamal cryptographic key pair used in Zether. Register the shielded-account on the Zether contract corresponding to the user’s token (MilesToken or SampleCoin). Fund the Zether contract (fund function) with the amount of tokens to be transferred. Create a single-use Ethereum account for the DvP transaction. Initiate the DvP transaction using the startDvP function. This function takes the following parameters: sender: public key of the sender’s shielded-account; receiver: public key of the receiver’s shielded-account; amount: amount of Zether tokens to be transferred; signer: single-use Ethereum account; zsc: address of the ZSC corresponding to the token to be transferred. The startDvP function generates the ZKP on the client side using the private ElGamal key associated with the user’s account, among other parameters. Confirm the DvP using the executeDvP function, which takes the following parameters: senderEthAddress: single-use Ethereum account generated in step 4 or returned by the startDvP function if not provided; counterpartyEthAddress: single-use Ethereum account of the counterparty; proof: ZKP generated in the previous step (startDvP).
Both parties involved in the DvP transaction need to complete all the above steps, and the Zether protocol does not specify how the shielded-account public keys and Ethereum account addresses are informed to the other party. Another noteworthy aspect is that Zether addresses the issue of front-running using the concept of epochs, in which time is divided into configurable blocks of x seconds. During an epoch, accounts involved in a transaction are locked, and transactions are rolled over only at the end of each epoch. The epoch is one of the various parameters used to generate Zether’s ZKPs. This means that both parties in a transaction need to synchronize their startDvP and executeDvP function calls within the same epoch; otherwise, the verification of the ZKPs in the DvP execution step will fail.
In the original application, the DvP transaction is executed by the Miles2Coins smart contract on behalf of the users, ensuring atomic execution of transfers. However, when using Anonymous Zether, the Miles2Coins contract cannot perform the transaction since it does not possess the private keys associated with the users, which are necessary for generating the ZKPs.
Furthermore, as previously mentioned, for users to perform startDvP and executeDvP transactions through Anonymous Zether, they must know the ElGamal public key of the shielded account and the single-use Ethereum address of the other party. Additionally, they need to synchronize with each other to execute the operations within the same epoch.
Therefore, Miles2Coins would need several adaptations to mediate this information exchange between parties. This would require changes to existing functions, the incorporation of additional cryptographic techniques, and the development of new functions to facilitate the exchange of necessary information and coordination of the DvP transaction timing.
Given the premise of avoiding major structural changes to Miles2Coins and Anonymous Zether, these adaptations were not pursued to prevent excessive coupling between the application and Anonymous Zether. Instead, this work assumes that when the Miles2Coins contract receives an offer acceptance transaction (acceptOffer function), it will simply emit the offerAccepted event. Upon detecting this event, the involved parties must use external means to negotiate the required parameters—for example, ElGamal public keys and single-use Ethereum addresses—and agree on the exact timing of the DvP transaction to be executed via Anonymous Zether. This communication could be carried out using secure peer-to-peer messaging protocols such as Waku 86 or other secure methods as deemed appropriate.
Transaction flow
Figure 2 illustrates a typical transaction flow in the privacy-enhanced Miles2Coins application, showcasing the interaction between User A (Alice) and User B (Bob) and the blockchain, where both Miles2Coins and Anonymous Zether are used to facilitate an offer agreement and execute a DvP transaction while preserving privacy. The transactions proceed as follows: Placing an offer: Alice, seeking to buy or sell MilesTokens in exchange for SampleCoins, initiates the process by calling the placeOffer function on the Miles2Coins contract, specifying the amount of tokens to be negotiated, the price, and whether she is buying or selling. Miles2Coins stores the offer and emits the offerPlaced event on the blockchain, which contains an ID and other details of the offer. Listing the active offers: Bob, interested in reviewing available offers, invokes the listOffers function. Bob receives a list of all active offers, including the one placed by Alice. Accepting an offer: After reviewing the offers, Bob accepts Alice’s offer by calling the acceptOffer function and providing the offer ID. This triggers the offerAccepted event on the blockchain. Alice reads the events and detects that her offer has been accepted. DvP parameters negotiation: As previously discussed, Alice and Bob must communicate to negotiate the parameters for the DvP transaction and the exact time for the transaction. Initiating the DvP transaction: Once the DvP parameters are agreed upon, Alice starts the DvP process by calling the startDvP function on the Anonymous Zether application. This includes providing parameters such as the users’ ElGamal public keys and the transaction amount, and generating the ZKP assuring the transaction’s validity. Around the same time, Bob also calls the startDvP function to initiate his side of the DvP transaction. The blockchain registers these actions as the dvpStarted event. Completing the DvP transaction: Alice and Bob each call the executeDvP function, submitting their single-use Ethereum addresses and the ZKPs generated in the startDvP transaction. At this point, the tokens are privately exchanged and the transaction becomes irreversible.
Privacy-enhanced Miles2Coins—transaction flow.
This experiment involves implementing the transaction flow described above in Miles2Coins, using a specific scenario where Alice acts as the seller of MilesTokens, while Bob purchases them using SampleCoins. First, to assess the performance and transaction costs of the original Miles2Coins, Steps 1 to 3 of the flow were implemented directly within the application, without privacy. In this case, when Alice calls the placeOffer function to sell MilesTokens, the smart contract receives her approval to execute the token transfer on her behalf. Similarly, when Bob accepts the offer, the contract also receives his approval to transfer his tokens. This allows the acceptOffer function in Miles2Coins to execute the DvP transaction on behalf of the users. Since privacy is not enabled in this scenario, all transaction details remain publicly visible. Next, another flow was implemented using Anonymous Zether to ensure privacy in Steps 5 and 6, which specifically concern the DvP transaction. The complete documentation of both flows is available in the “examples” directory within the Miles2Coins repository. 85
This section reports on the experimental evaluation of Miles2Coins and its integration with Anonymous Zether, aiming at answering the following key questions:
What is the total gas required to execute a DvP transaction publicly, using the original Miles2Coins application, or privately, through integrating it with Anonymous Zether?
What is the performance impact on the application due to the privacy enhancement?
What level of privacy is achieved after integrating the privacy solution?
What are the practical challenges related to implementing privacy in DvP transactions?
Overall, the experimental results demonstrate that the gas costs for the privacy-enhanced Miles2Coins application are significantly higher than those for the original Miles2Coins. Moreover, the execution of transactions requires more time and consumes more computational resources, such as CPU and RAM. Additionally, there are other challenges in integrating privacy into DvP transactions, which may reduce the overall level of privacy achieved.
Gas costs are a critical factor for applications deployed on Ethereum. The more operations a transaction performs on-chain, the higher its gas cost. Resource-intensive operations that require significant CPU and storage usage generally incur higher gas fees. A recurring challenge for various ZKP-based privacy solutions is the substantial gas cost of cryptographic operations executed on-chain. In the Anonymous Zether paper, 32 the estimated gas cost for a single transfer operation is nearly 4.8 million gas.
Therefore, it is essential to analyze the gas costs of Miles2Coins transactions, along with the additional costs introduced by incorporating Anonymous Zether for the final DvP transaction. Tables 2 and 3 present the gas costs associated with Miles2Coins and Anonymous Zether transactions, respectively.
Miles2Coins gas costs.
Miles2Coins gas costs.
Notes:
Anonymous Zether gas costs.
Notes:
It can be noted that the gas costs of Anonymous Zether transactions is indeed significantly high. Although these costs were previously reported in the Zether 11 and Anonymous Zether 32 papers, neither included an analysis of DvP transactions. In this case, the total cost of the required operations—currently around $308.08—renders its implementation on Ethereum impractical. Therefore, if Miles2Coins were to be integrated with Anonymous Zether in a production environment, alternative blockchains such as Polygon PoS 89 or BNB Smart Chain, 90 known for their lower transaction fees, should be considered.
The performance impact of executing the DvP transaction stage through Anonymous Zether must be carefully analyzed. For this experiment, the Hardhat Network was configured to automine transactions to ensure that the blockchain network throughput would not affect the test results.
Table 4 presents the CPU and RAM usage, as well as the time required to execute the complete transaction flow in the original Miles2Coins application, which comprises the following transactions: placeOffer (user A), listOffers (user B), and acceptOffer (user B), which includes the DvP transaction. The table provides two sets of data: one for a single execution of the complete flow and another for 100 consecutive executions of the same flow.
Miles2Coins performance.
Miles2Coins performance.
DvP = delivery-versus-payment; CPU = central processing unit; RAM = random access memory.
To specifically evaluate the performance of the DvP transaction using Anonymous Zether, up to 32 accounts were created, each receiving 10,000 SampleCoins and 10,000 MilesTokens. These tokens were used to fund their respective Zether contracts—ZSC1, representing the private version of SampleCoin, and ZSC2, representing the private MilesToken. A script was developed to take a specific pair of users as input and execute the four sequential steps required to complete the DvP transaction between them:
startDvP for user A, who is selling MilesTokens (ZSC2 tokens). startDvP for user B, who is purchasing MilesTokens and transferring SampleCoins (ZSC1 tokens). executeDvP for user A, confirming their part of the DvP transaction. executeDvP for user B, confirming their part and completing the DvP transaction.
With this setup, JMeter was used to execute the script and perform DvP transactions in parallel among multiple user pairs. Initially, only two users were simulated (a single DvP transaction), then the number was progressively doubled until reaching 32 users (resulting in the parallel execution of 16 DvP transactions). Table 5 shows the CPU and RAM usage, as well as the time required to complete all transactions.
Anonymous Zether DvP performance.
DvP = delivery-versus-payment; CPU = central processing unit; RAM = random access memory.
Anonymous Zether introduces a significant performance overhead in DvP transactions. A single transaction using Zether takes over 11 s—nearly 28 times slower than the 401 ms required for the entire flow (including the DvP transaction) in the original Miles2Coins application. Processing 16 transactions through Zether consumes over 2 GB of RAM and takes more than 2 min, resulting in a throughput of only 7.26 transactions per minute.
Although the experimental machine has six cores and 12 threads, the Hardhat Network node process does not support multithreading. Thus, JMeter was only effective in parallelizing locally executed operations within the JavaScript code, such as the generation of ZKPs. On-chain operations performed by the Zether contracts, such as ZKP verification and encrypted balance updates, significantly impacted performance due to the lack of multithreading. This behavior is evident in Figure 3, which shows that all 12 logical CPUs were utilized during the initial 20 s, after which only the highlighted CPU handled the remaining processing. While the experiments were conducted on a single machine, using multiple machines (e.g. one per user) would only help parallelize local computations. Blockchain operations would remain unaffected, as all transactions must be processed sequentially and in the same order by every node in the network.
Anonymous Zether CPU usage—16 DvP Tx. DvP = delivery-versus-payment; CPU = central processing unit.
As previously mentioned, Anonymous Zether employs the concept of epochs to divide time into configurable blocks, with a default duration of 6 s. However, due to the complexity of DvP transactions, the epoch had to be extended to 120 s during the tests—and even to 240 s for the test involving 32 users—to prevent errors in ZKP verification, as these proofs use the epoch as an input parameter. As a result, after processing the transactions, the new balances of the involved accounts were only updated at the end of the configured epoch, leading to delays of up to 4 min in the worst-case scenario.
Obtaining transaction details on Ethereum or other blockchains without additional privacy features is straightforward. Transacted values, along with sender and recipient addresses, can be directly accessed from the raw transaction data. With the ABI (application binary interface) of a smart contract, which defines its functions and data structures, one can decode transactions to determine exactly which functions were invoked, the parameters used, and the outputs generated. Therefore, in the original Miles2Coins application, it is easy to identify which accounts placed or accepted offers, as well as the amounts of MilesTokens exchanged for SampleCoins and vice versa.
Additional privacy is introduced by implementing the final part of the flow, which involves DvP transactions, using Anonymous Zether. These transactions become confidential, preventing external observers from determining which tokens were exchanged or in what amounts. However, since the placeOffer and acceptOffer transactions remain unprotected, it is still possible to infer how many tokens each account holds, though without certainty regarding which trades were actually completed.
In addition to making DvP transactions confidential, Anonymous Zether includes the anonymity sets feature, as described in Section 4.3, to hide the sender and recipient accounts. Unfortunately, this functionality could not be tested in this work. The reason for this issue is that the startDvP function in the Anonymous Zether client was not initially configured to receive the “decoys” parameter required to create the anonymity set. After modifying the function to accept this parameter, further issues emerged: the deserialization of the “decoys” vector was not functioning correctly, and upon fixing it, an error occurred during ZKP generation. This suggests that the feature is not fully operational in the current version of Anonymous Zether.
Consequently, it was decided not to proceed with fixing these issues, adhering to the premise of avoiding deep changes to the solution. Although the anonymity sets feature was not utilized, the use of single-use Ethereum accounts for each transaction still contributed to some degree of anonymity. Nonetheless, the performance tests presented here provide a baseline for evaluating the solution’s minimum overhead, as incorporating anonymity sets would further impact performance, as demonstrated in the Anonymous Zether paper. 32
Practical challenges
Enhancing the privacy of a blockchain-based application is both an intriguing and valuable research endeavor. However, it presents challenges from the outset, starting with the selection of an appropriate approach. Strategies range from directly applying known techniques, such as encryption and hashes, to integrating existing privacy solutions. The case study conducted in this research aimed to evaluate the integration of the Anonymous Zether privacy solution with the sample application Miles2Coins, which has well-defined privacy requirements, as it enables token swap transactions that could be highly valuable in a real-world scenario. As expected, several difficulties arose during this process. This section summarizes the challenges encountered and the strategies used to address them.
Selecting the right privacy solution
The initial challenge is selecting an appropriate privacy solution, as each approach comes with its own features and trade-offs that can either facilitate or hinder implementation. There is no universal solution that provides maximum privacy for all applications without drawbacks. In this work, to align with Miles2Coins’ requirements, a structured selection process was followed (Section 4.2). Delegation-based solutions were excluded due to trust assumptions, and only Ethereum-compatible options with public repositories were considered. Additionally, solutions requiring a trusted setup or lacking anonymity were discarded. Based on these criteria, Anonymous Zether was chosen for ensuring transaction confidentiality, balance privacy, and anonymity while minimizing trust dependencies. However, the experiment revealed certain limitations that could affect its practicality in real-world applications, as discussed further below.
Integration challenges
Like most privacy solutions, Anonymous Zether is not a plug-and-play tool but rather requires a deep understanding of its functionalities. The limited and incomplete documentation of Zether further complicates this task. An important constraint is that the solution is restricted to token transfers and other simple operations, meaning it cannot enhance the privacy of arbitrary smart contract functions. Furthermore, while the author of Anonymous Zether described a mechanism for private DvP transactions in a research paper, 79 this implementation is absent from the official Anonymous Zether repositories75,80 and is only available in the Drex project repository, 81 as mentioned in Section 4.3.
Additionally, Zether supports only fungible tokens—such as ERC-20 67 and ERC-1155 66 —but does not support non-fungible tokens (NFTs) like ERC-721. 68 Since Miles2Coins deals exclusively with fungible tokens, this limitation is not an issue in this case, but for applications requiring NFT support, Zether would be unsuitable. Finally, the low modularity of Anonymous Zether makes its integration with Miles2Coins significantly more complex, particularly when aiming for a seamless experience for the end user. A fully integrated implementation would require deep modifications to both solutions, leading to strong coupling and limiting applicability to other use cases.
Using Zether exclusively for Miles2Coins
As noted by Benedikt Bünz, one of the original authors of Zether, 91 users should ideally perform all transactions using Zether tokens to maximize privacy. However, this is unfeasible unless Zether is widely adopted. Thus, integrating Zether solely into Miles2Coins and its associated tokens introduces a privacy weakness: the original tokens—MilesToken and SampleCoin—are public both before and during the funding of their respective Zether smart contracts. This means that external observers can determine how many tokens a given account holds before they are converted into their shielded Zether equivalents. For instance, if a user deposits 100,000 MilesTokens into the ZSC contract, this initial transaction is public, and only subsequent transactions remain confidential. The same issue arises when converting ZSC tokens back into their original form. This problem could only be mitigated if the tokens were originally issued as Zether tokens, which, in a real-world scenario, would require airlines and the SampleCoin issuer to adopt Zether as the foundation for their tokens.
Transaction costs and performance overhead
Despite its compatibility with Ethereum, using Anonymous Zether for DvP transactions proved impractical due to prohibitive gas costs, as detailed in Section 6.1. Consequently, its applicability may be limited to blockchains with significantly lower or configurable transaction fees, or to applications where high transaction costs are justified. Performance overhead was also substantial. While it was not a completely limiting factor for Miles2Coins, applications with stricter performance requirements would likely be unable to integrate Anonymous Zether effectively.
Epochs and synchronization issues
The division of time into epochs, while effective in preventing front-running attacks, causes two undesirable side effects. First, parties must coordinate their operations to complete a DvP transaction within the same epoch. Second, all accounts involved in the transaction—including “decoy” accounts used for anonymity—become temporarily locked. None of these accounts can execute transactions during the same epoch, as doing so could lead to inconsistencies with the balance values included in the ZKPs. Moreover, in the experiment, the epoch duration had to be extended, significantly reducing transaction throughput.
Absence of anonymity sets
As discussed in Section 6.3, the anonymity sets feature was not functional in the available implementation of Anonymous Zether. Consequently, no additional anonymity was achieved for the parties involved in DvP transactions. The only factor contributing to some level of anonymity was the use of single-use Ethereum accounts—a best practice already recommended for public blockchains such as Bitcoin and Ethereum.
Limited privacy scope
As described in Section 5, Anonymous Zether could not be integrated into the offer placement and acceptance phases of Miles2Coins, meaning that privacy enhancements were limited to the DvP transaction. Although other blockchain users cannot observe the DvP transaction details, they can still view existing offers and determine which ones were accepted. This enables them to infer which accounts likely hold certain token amounts, reducing the overall level of privacy.
Feasibility of end-to-end privacy on public blockchains
Given the limited privacy achieved by incorporating Anonymous Zether, it is worth exploring how privacy could be extended to other transactions in Miles2Coins. This section highlights the additional difficulties that would arise, providing insight into the privacy paradox in a public and distributed blockchain environment. This discussion leads to the key question: is it possible to achieve full end-to-end privacy on public blockchains?
If Miles2Coins followed the traditional web-based approach, it would likely be hosted on a website secured with TLS encryption. In this setup, the placeOffer and acceptOffer functions would be accessible within the application’s authenticated area. Consider Alice and Bob, who want to sell and buy airline miles, respectively. After logging in, Alice could register a sale offer, triggering the automatic reservation of her miles via API integration with partner airlines. Active offers could then be viewed by other users, but the seller’s identity would remain hidden. Only the offer IDs, the quantity of miles, and the price would be visible. When Bob accepts a sale offer, he would proceed to a secure payment page, and the application would manage the swap transaction, ensuring Alice receives the payment and Bob receives the miles. In this centralized model, assuming both users trust the Miles2Coins platform and its operator, user privacy would be preserved because transaction details would only be accessible to the involved parties and the platform itself. Offer data could also be encrypted in the database, preventing even internal administrators from accessing sensitive transaction details.
In the blockchain-based version of Miles2Coins, encrypting offer data presents significant challenges. Allowing users to access encrypted offer information without exposing sensitive data would require additional communication mechanisms. If this communication is performed on-chain, it could potentially be exposed or become prohibitively expensive. For instance, if Alice encrypts her offer details with a symmetric key, how would Bob access the content? If Alice shares the encryption key through an on-chain transaction, the key would be visible to all nodes on the blockchain, compromising confidentiality. Similarly, smart contract-based encryption fails because contract logic executes transparently, exposing plaintext during decryption. Using ZKPs for offer registration, where Alice proves that the offer is valid and that she holds the necessary tokens, would make listing offers impractical, as interested buyers would not have access to the actual offer data. Furthermore, if only sellers retained access to their offer data, buyers would need to communicate directly with all sellers off-chain to retrieve information about available offers. Even ring signatures, while obfuscating pseudonyms, demand large anonymity sets to prevent probabilistic deanonymization, adding operational complexity without guaranteeing absolute privacy. Each of these approaches introduces significant obstacles that cannot be resolved without compromising data confidentiality, degrading usability, or dramatically increasing complexity.
This study demonstrates that achieving complete, end-to-end privacy on a public blockchain solely through on-chain mechanisms is highly challenging in many scenarios. While certain use cases, such as cryptocurrency transfers,17,18 auctions, 11 and voting, 52 demonstrate context-specific privacy successes, there is no “one-size-fits-all” solution for full end-to-end privacy that works across diverse applications without significant trade-offs. These trade-offs include:
Off-chain interaction: Most privacy approaches cannot operate entirely on-chain without exposing intermediate data to all nodes. Solutions like ZKPs often require client-side computation and off-chain key management. Similarly, TEE-based solutions rely on off-chain environments to handle private computations. Partial privacy compromise: If the goal is to keep all transaction details, user balances, and business logic hidden, purely on-chain solutions face inherent limitations, as shown in this case study. On the other hand, delegation-based solutions would require users to trust TEEs or managers, partially compromising their privacy. Some degree of centralization: Techniques such as SMPC and delegation-based approaches often rely on a subset of nodes or specialized infrastructure to process transactions securely. Besides reducing privacy, this introduces a certain level of centralization, which conflicts with the fully decentralized essence of public blockchains.
Enhancing privacy in blockchain systems remains a widely discussed challenge. The very nature of blockchains is to make transactions public, and the obstacles to improving user privacy in this scenario are numerous, starting with performance impacts and the high transaction costs of on-chain solutions. Off-chain approaches, such as delegation-based methods, typically offer better performance and lower costs but may compromise privacy and increase dependency on third parties. Solutions leveraging ZKPs usually involve performing cryptographic computations on the client side, resulting in higher complexity and significant computational overhead for users. Finally, solutions that combine ZKPs and HE promise intermediate performance, but their on-chain operations can lead to high gas costs, particularly when deployed on Ethereum.
Therefore, while significant privacy enhancements are possible through various techniques, public blockchains currently lack straightforward, purely on-chain methods for achieving complete confidentiality across all aspects of an application. Developers often need to combine multiple techniques, accept partial data exposure, or incorporate off-chain components to secure sensitive information. These limitations highlight the need for further research and privacy-focused protocol layer innovations. Until such advancements materialize, developers must navigate a complex landscape of compromises, balancing transparency with privacy requirements.
The integration of privacy solutions into existing applications is an underexplored area in the literature. This study conducted an empirical evaluation of the challenges involved in such integration, analyzing the resulting privacy enhancements alongside their impact on performance and transaction costs. Although the results suggest that deploying the privacy-enhanced Miles2Coins application on the Ethereum mainnet would be impractical, primarily due to high transaction costs, the insights gathered from this research can be applied to other decentralized applications and privacy-preserving solutions.
Future work will focus on testing the integration of Anonymous Zether into a real-world DeFi application, such as a DEX. Additionally, performance and cost evaluations will be conducted on alternative blockchains like Polygon PoS 89 or BNB Smart Chain 90 to assess whether lower gas fees and higher throughput on these platforms could improve the feasibility of this approach in broader scenarios.
Functional and practical analyses of privacy solutions for blockchain, such as the one presented in this study, are essential not only for helping decentralized application developers identify viable solutions to enhance user privacy but also for encouraging researchers and blockchain platform enthusiasts to further explore novel privacy-preserving techniques and solutions.
Footnotes
Funding
The authors received no financial support for the research, authorship, and/or publication of this article.
Declaration of conflicting interest
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.