It is well known that pseudonymity in blockchains such as Bitcoin or Ethereum does not really hide the identity of the author of a payment. A number of attacks have been documented in the literature to deanonymize blockchain transactions. This is also the case of fully anonymous blockchains such as Monero and ZCash for which trafic analysis methods can be used. The goal of this paper is to outline a solution to the above problem in the most general (and dificult) case, namely that of pseudonymous blockchains. We restrict to the case of blockchains supporting smart contracts, with specific reference to Ethereum. Borrowing an approach used in the context of anonymous communication networks, we design a solution supporting -anonymous payments against every eavesdropper, including the network adversary. Roughly, the idea is to organize users in rings of cover transactions, through which users indistinguishably exchange actual data or random noise and the initiator is hidden within the ring. Importantly, no of-chain communication is required.
Blockchain is a distributed ledger that keeps track of the occurrence of events. An entity can generate a transaction toward another entity to exchange a value. This transaction is validated by peers participating in the network, and thus does not require any third-trusted party to be validated.
A relevant feature ofered by the most known blockchains (e.g., Ethereum and Bitcoin) is
pseudonymity. Each user is associated with an address (not directly linked to the real identity of
the user) that allows them to send and receive cryptocurrency. Nevertheless, all the transactions
a user makes with the same address are linked among them. In the literature, several works
were proposed concerning the de-anonymization of blockchain addresses [
Diferent blockchains such as Monero and ZCash ofer full anonymity [
As a matter of fact, transactions generate trafic in the network. Therefore, no resistance against the network adversary playing as a global eavesdropper can be achieved if this aspect is not taken into account. Obviously, the trivial idea of interposing an anonymous routing protocol (even resistant to the global observer) between the client and the pseudonymous blockchain cannot work, because the goal is not to hide the network address of the client but their blockchain address, which would be anyway public.
However, anonymous communication networks [
It is worth noting that our solution has completely ethical goals. Indeed, we are aware that anonymity in payments is often pursued by the crime. However, this is not the case of our solution, in which anonymous payments are allowed only to registered services and, then, potentially subject to verification.
This paper is a work-in-progress paper. Therefore, the proposal is only sketched and some
components (also regarding the security analysis) still need to be processed. Moreover, even
though the design of the solution is done on the basis of the features ofered by Ethereum and
its smart contracts [
The structure of the paper is the following. In section 2, we investigate the related literature. We describe the proposed solution in Section 3. Its security is analyzed in Section 4. Finally, in Section 5, we draw our conclusion.
In this section, we provide a brief overview of the literature related to our work.
Our goal is to implement payments on Ethereum ensuring -anonymity for the payment initiator, making them undetectable even by network adversaries with uncertainty less than 1/, where represents a parameter for the desired degree of anonymity.
Transaction anonymity could certainly be achieved using anonymous blockchains like ZCash
[
In pseudonymous blockchains, several approaches have been proposed, typically based on
transaction mixing, to make transactions untraceable, such as [
In particular, [
[10] delves into resolving privacy concerns stemming from Bitcoin transparent nature by introducing concepts of “micropayment channels", which enable secure, immediate, and confidential transactions. It addresses storage limitations, facilitates transactions involving untrusted intermediaries, and showcases its viability in currencies.
[11] explores the balance between the trustless aspect of decentralized currencies and the compromised privacy of transactions. It proposes enhancing regulatory compliance and tracking of tainted coins by introducing privacy-preserving mechanisms.
[12] proposes an Ethereum solution to provide anonymous services with accountability guarantees.
However, no one of the above proposals considers the threat model of a global (network) adversary.
Other works that combine blockchain and -anonymity do not address the execution of anonymous payments, namely [13] and [14]. These solutions utilize blockchain as a framework for data management and leverage -anonymity for anonymous data sending and exchanging. Despite this, these works do not achieve the goal of our work.
As highlighted in the introduction, we borrow from the context of Anonymous
Communication Networks (ACNs) [
As observed in [15], the existing routing methods for P2P overlay networks, which resist
the global passive adversary [16], mostly require the inclusion of cover trafic [
There are two primary strategies that utilize cover trafic. The first approach, known as “buses" [22, 23, 24], involves the sender following a predefined route to anonymously communicate with the destination. These works introduce innovative protocols for anonymous communication, drawing inspiration from public transportation systems. They aim to conceal trafic patterns and ensure message anonymity, ofering either deterministic or randomized approaches. The second approach, known as “mixnets" [25, 26], generally ofers lower latency but requires more cover trafic. In particular, the approach presented in [ 26] is burdened by substantial communication overhead. [27] discusses challenges in onion mixnets within anonymous communication networks, to obtain sender anonymity against the global adversary. Also [? ] deals with anonymous communications, emphasizing privacy in public networks. The study also examines verifiable mixnets and their applicability to electronic voting, concluding with a brief mention of other anonymity-based systems.
The idea of our work is to use cover transactions instead of cover trafic. However, a mixnetbased solution would not be feasible due to the large amount of cover trafic required [ 19]. For these reasons, our work is based on the buses approach.
[28, 29] present some similarities with our approach since they deal with the idea of flow security. The focus is the examination of security attributes within computer systems, in particular enduring properties. These approaches denote that if a system maintains security at any given instance, subsequent states also retain security. Information flow security properties have emerged as a fundamental mechanism for upholding the confidentiality of classified information. These properties serve to manage the transfer of information among distinct groups of entities characterized by difering security levels.
Their goal difers from ours, as they may prioritize diferent objectives. Consequently, the methodologies they employ may not align with our specific needs, so their methods are not directly applicable in our context.
Our approach enables users to transfer money in an anonymous way in a pseudonymous blockchain. In addition, our solution does not require any of-chain interaction, thus all the operations are performed through the blockchain.
The core concept of this solution involves grouping users into sets named rings (as illustrated in Figure 1). A ring serves as an anonymity set, ensuring that when a user within a ring initiates a payment, their identity remains indistinguishable from other ring users. The solution incorporates an information-hiding mechanism within the ring, achieved through the continuous circulation of cover transactions.
These cover transactions are blockchain transactions moving sequentially between adjacent ring users. They may carry either actual or dummy data. These data are probabilistically encrypted by a user with the Ethereum public key of their next in the ring. This way, no external party can tell whether a given transaction is carrying dummy or actual data.
At a broader level, the solution utilizes a smart contract where users initially deposit an equal amount of currency. This deposited sum can be spent later in an anonymous way. Each ring user is linked to a pseudonym, distinct from their Ethereum address. Users maintain private ledgers that associate pseudonyms with balances. However, the mapping between pseudonyms and Ethereum addresses is unknown to the users.
To execute an anonymous payment, a user awaits a cover transaction containing dummy data, which is then replaced with actual data detailing the intended payment (e.g., pseudonym of the sender, recipient, amount). This transaction is forwarded in the ring hop by hop so that, at the end, its content is shared with all the users. Given the pseudonymous, each user in the ring updates their private ledger (i.e., decrements the balance of the pseudonymous of a given quantity). In this manner, each user in the ring is aware that a particular pseudonym has initiated a payment but does not know the corresponding Ethereum address.
Ultimately, the smart contract executes the actual payment after receiving a specified number of confirmations from ring users.
The main idea of our solution revolves around arranging a collection of users into a cyclically ordered set, named ring, as depicted in Figure 1. A set of rings is called realm. The realm is managed through a smart contract, say . has three main goals: (1) management of the users willing to join the system (potential senders of anonymous payments), (2) building of the rings from the realm, and (3) management of the service providers (potential recipients of anonymous payments).
We now describe how reaches goal (1). To enter a realm, each user should deposit a sum of cryptocurrency = + + in the smart contract . is the amount that can be later on spent in an anonymous way. is a security deposit that serves as an incentive for users to collaborate in the ring. stands for the fee necessary to cover the management of each ring.
Each ring is composed of + users. is a parameter defining the anonymity degree of the system, and is the assumed maximum number of non-collaborating users in a ring. The meaning of and is that, when at most users do not collaborate, we can obtain that the initiator of a payment is still indistinguishable among users against a network eavesdropper (thus, obtaining -anonymous payments).
Now, we describe how the rings of a realm are built, i.e., goal (2). The ring construction should happen in a fully decentralized way, such that no of-chain interaction is required. To reach this goal, we propose a mechanism based on a Distributed Hash Table (DHT) that allows the users to find the ring to which they belong, through their Ethereum address. However, if this computation depended only on the Ethereum address of each user, another problem would arise. Indeed, for an anonymous payment to be executed, our solution requires at least confirmations among the + users in a ring. Then, an adversary could perform a sibyl attack by generating a lot of Ethereum addresses to find at least addresses that would belong to the same ring. This way, they would be able to control the ring and spend the cryptocurrencies of the other users.
We recall that each user joining the system should pay an initial sum of cryptocurrency. This also works as a disincentive for an adversary to try joining the system with multiple Ethereum addresses. Moreover, if users were not able to precompute the ring in which they would fall, the adversary would have to generate (and pay for) a greater number of addresses to increase their chance of having at least addresses in the same ring. Then, the economic efort required from the adversary would be high.
To achieve this, we propose the following mechanism. Suppose the realm includes users being split into rings of size + . As above mentioned, each user deposits a given amount of cryptocurrency in the smart contract to become part of a ring. To do this, the users simply invoke a function of that collects their deposits and stores their Ethereum addresses. However, the rings are not formed until the ℎ user asks to join a ring. When the ℎ user joins the realm, the invoked function performs in a slightly diferent way. After collecting the deposit and storing the Ethereum address of the ℎ user, the function retrieves and stores the height of the last block included in the blockchain. The idea is to use the hash of a future block whose distance is a fixed number from the stored one. Thus its hash serves as an unpredictable value to implement the DHT and prevent any adversary from precomputing the rings to which the users belong.
Specifically, when the block including the last transaction is mined and added to the blockchain, any entity can invoke another function that retrieves the digest of such a block, say . Then, for each user with Ethereum address ℎ, a value = (ℎ||) is computed and associated with ℎ, where denotes a cryptographic hash function. Then, these values are ordered in an increasing way to form the rings. Specifically, the first + values form the ifrst ring, the next + values form the second ring, and so on. Observe that, since is not known before the last user joins the system, the users cannot precompute in advance the rings they fall.
Ultimately, each ring is created by deploying a smart contract (per ring), say , in the blockchain. is responsible for the execution of anonymous payments. A thorough explanation of how these payments can be issued is given in Section 3.3.
We now explain how handles the service providers willing to be potential recipients of the anonymous payments, i.e., goal (3). These providers are the sole entities that can receive anonymous payments. In the system, there are a number of Attribute Authorities that can dynamically add to the system Service Providers. Attribute Authorities are responsible for the verification of the requirements of the Service Providers to belong to the system.
In this section, we describe the anonymous payment mechanism in a ring. This mechanism is handled via the smart contract associated with the ring.
Consider a user willing to initiate an anonymous payment of Ethers to a service provider . First, should wait for a cover transaction, containing dummy data, from their previous user in the ring. Then, should replace the dummy data with the actual data = ⟨ , , , , ℎ′ , ⟩, wherein is a random identifier for data , and ℎ′ represents the Ethereum address of another randomly chosen user ′ in the ring, referred to as the exit-user. is a signature computed over ⟨ , , , , ℎ′ ⟩ verifiable using , i.e., a public key serving as pseudonymous for .
Then, is encrypted with the Ethereum public key of the user succeeding in the ring and transmitted via a cover transaction. We recall that no external party should be able to state if a cover transaction is carrying dummy data or actual data.
The cover transaction completes a full loop in the ring, with all users locally storing its data and verifying the signature using . Upon reaching again, the same cover transaction is sent to the next user in the ring. This process repeats for a second loop until it reaches the exit-user, say ′. At this point, ′ empties the cover transaction, i.e., replaces the actual data within such a transaction with dummy data.
In the meanwhile, each user in the ring tosses a biased coin, and then with probability , each user invokes a function of to authorize the payment passing ⟨, , ⟩ as input.
When the smart contract receives at least authorizations, it transfers the amount from its local balance to . Here, ( 2 + 1 ≤ ≤ ) is a system parameter serving as a safeguard against malicious or non-cooperating users attempting to obstruct a legitimate payment.
Finally, all users in the ring update the balance associated with in their internal ledger.
Figure 1 shows a graphical representation of this procedure.
Our solution requires that each sender of payment should be at least -anonymous, i.e., they should be disguised among at least other users in the ring. Thus, given that the ring is composed of + users, in a ring there may be at most non-collaborating users, otherwise the anonymity threshold cannot be satisfied. We recall that the amount of cryptocurrency (initially deposited) by each ring user is fixed in advance. So if depletes the amount before other users in the ring, they will not be able to make additional anonymous payments but must continue to collaborate to facilitate the anonymous payments of other users within the ring. Thus this user may be disincentivised to further collaborate in the ring, since collaborating implies paying for making the cover transaction circulating in the ring and sending confirmations to the smart contract. To prevent this, we introduce a security deposit mechanism. Each user , in joining the system, must deposit an amount . This deposit will be fully refunded to the users who collaborate until the end of the ring. A huge deposit would certainly make users collaborate till the end. However, this is little realistic. Similarly, a small deposit may not be enough to incentivize users. To estimate a plausible value for , we first need to estimate the ring lifetime and thus the maximum amount of expenses necessary to carry out the anonymous payments until the end of the ring. To do so, we split the ring lifetime into epochs. We denote by an epoch of the ring and by the sum of all the deposits from ring users left in the epoch . In the first epoch (say ˆ), ^ = ∑︀(=+1 ) . Then, we set a minimum threshold for each payment that, as we will see, does not prevent the user from paying less than . Since we aim to guarantee service continuity for all the users, an epoch ends once a user , after payments, terminates the amount . Thus, the maximum number of payments in an epoch is given by ∑︀(=+1) , where is the amount of cryptocurrency for user (initially set to ) left for the anonymous payments at the epoch .
Observe that, since in general the amount of cryptocurrency that a user is willing to pay to a service provider may not be an integer multiple of , each payment may generate a change. We say the entire amount of changes. At the end of each epoch, the changes will be returned to their owner in the ring (i.e., each user in the ring updates their private ledger accordingly). Observe that, an epoch ends once at least a user terminates the amount but still owns a fraction of the changes . Once is ended, we compute the amount of deposit necessary to advance the next epoch, say ′. The idea is that, at the end of the epoch , we can compute the amount of deposit ′ necessary to cover (in the worst case) the expenses in the subsequent epoch ′. Thus it will depend on the maximum number of payments that will be done during ′. Again, this number can be estimated according to the following formula: ∑︀(=+1)′ .
Then the diferences between the deposit in the current epoch ( ) and the deposit necessary for the next epoch (′ ) will be given to each user ring. To incentivize collaboration among users in the ring, a portion of the deposit will be returned to ring users according to a score associated with how collaborative they were during each epoch. Specifically, given a user , the amount of deposit they will receive back is given by the following formula: ,· (− ′ ) , where ∑︀+ =1 , , is the score associated with during epoch . The computation of the score is left as future work.
Observe that, since the end of an epoch happens when at least one user makes a payment, it is always guaranteed that ′ < . So the process converges.
In this section, we analyze the security of our solution. Our analysis is founded on a basic assumption, which we call A1, that at most users are not collaborative in each ring. It is justified by the proposed incentive mechanism. Indeed, when users do not collaborate, they lose part of all of their security deposit. In addition, also the wallet amount is lost when a user does not collaborate. Indeed, we recall, that the payments are intended only to registered service providers. Then, users cannot transfer their remaining amount to another wallet under their control.
Adversary Model. We consider a global adversary with the capability of capturing all the network trafic exchanged by the users.
Observe that, in the blockchain network, any participant can observe the transactions performed by all users. However, all participants but those directly connected to the sender, do not see the IP address of the originator of a transaction. Our adversary is then much more powerful than standard users. In practice, it might correspond with one or more Internet Service Providers.
Security Goal. Our solution achieves sender anonymity [30]: the adversary cannot identify the initiator of a payment (sender) with probability greater than 1 .
To show this, we follow an approach similar to [19].
By Assumption A1, we consider the worst-case scenario in which in the ring of the sender there are collaborative users.
When a cover transaction is forwarded hop-by-hop, thanks to probabilistic encryption, the adversary cannot distinguish if it contains dummy data or the details of a payment. Then, the adversary cannot identify the sender when they fill the cover transaction with actual data.
Therefore, the only way for the adversary to identify the sender is to detect a possible transition from actual/dummy data or dummy/actual data of a cover transaction at another point of the ring and try to draw some information starting from this observation.
The only point of the ring from which the adversary can draw such information is the exit user.
We have to consider two cases.
The first case is when the cover transaction including the details of the payment reaches the exit user. In this case, they send the first confirmation of the payment towards the smart contract. The adversary can observe this confirmation to infer that a payment is performed. However, since before reaching the exit user, the cover transaction containing the details of the payment, performs at least a complete loop of the ring, these details may be inserted by any of the collaborative users in the ring.
Thus, in this case, the sender cannot be identified with a probability greater than 1
The second case occurs after all the confirmations are sent to the smart contract. In this case, the exit user inserts dummy data in the cover transaction so that it can be used for the next payment. This can be observed by the adversary.
However, the next observation of the adversary is again when another exit user sends the ifrst confirmation to the smart contract. This cannot happen before a complete loop of the ring is performed. Then, we are again in the first case and the sender cannot be identified with probability greater than 1 .
Another possible exploitable information for the attacker could be the confirmations. Indeed, the attacker could guess that the initiator of the payment is within (or without) the set of users sending the confirmation. This, in principle, could reduce the size of the anonymity set below the value . However, this is not the case because every user sends the confirmation with probability . Therefore, no bias occurs and no guess is possible for the attacker.
In this preliminary paper, we present a solution to achieve -anonymity in Ether payments to allowed registered services. Anonymity is reached in the most severe threat model, namely a global observer also capable of analyzing network trafic. The solution needs to be further processed (in some components) and implemented, also to test its feasibility in terms of costs. Indeed, a critical aspect to be analyzed is the cost of transactions and execution of smart contracts. However, from a first rough analysis not included in this paper for its incompleteness, costs appear unproblematic even for appreciable anonymity degrees.
A possible criticism of our solution could regard its plausibility in terms of customer acceptance and expected benefits. About this, we observe that our solution is not diferent from existing closed-loop prepaid payment systems in the domain of standard currencies. Moreover, prepaid systems in which money withdrawal is not allowed also exist, based on cards, phone credit or other kinds of electronic wallets. The benefits of our solution can be found in the ever-increasing demand for privacy that, sometimes, intersects with censorship resistance.
As future work, we plan to explore all the above aspects in depth, addressing both technical and business issues. Another possible future work is to study the migration of our approach, thought for payments in cryptocurrencies, to permissioned blockchains such as Hyperledger Fabric [31]. This issue is not trivial, because payments should be implemented by fungible tokens and, thus, we should investigate how to preserve the anonymity features of our solution when using tokens.
This work is partially supported by project SERICS (PE00000014) under the MUR National Recovery and Resilience Plan funded by the European Union - NextGenerationEU. tocurrency with enhanced accountability, IEEE Transactions on Dependable and Secure Computing 18 (2021) 679–691. doi:10.1109/TDSC.2019.2910058. [10] M. Green, I. Miers, Bolt: Anonymous payment channels for decentralized currencies, in: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS ’17, Association for Computing Machinery, New York, NY, USA, 2017, p. 473–489.
URL: https://doi.org/10.1145/3133956.3134093. doi:10.1145/3133956.3134093. [11] C. Garman, M. Green, I. Miers, Accountable privacy for decentralized anonymous payments, in: Financial Cryptography and Data Security: 20th International Conference, FC 2016, Christ Church, Barbados, February 22–26, 2016, Revised Selected Papers 20, Springer, 2017, pp. 81–98. doi:https://doi.org/10.1007/978-3-662-54970-4_5. [12] F. Buccafurri, V. De Angelis, S. Lazzaro, A blockchain-based framework to enhance anonymous services with accountability guarantees, Future Internet 14 (2022). URL: https://www.mdpi.com/1999-5903/14/8/243. doi:10.3390/fi14080243. [13] Y. Long, Y. Chen, W. Ren, H. Dou, N. N. Xiong, Depet: A decentralized privacy-preserving energy trading scheme for vehicular energy network via blockchain and k - anonymity, IEEE Access 8 (2020) 192587–192596. doi:10.1109/ACCESS.2020.3030241. [14] B. Sowmiya, E. Poovammal, A heuristic k-anonymity based privacy preserving for student management hyperledger fabric blockchain, Wireless Personal Communications 127 (2022) 1359–1376. doi:https://doi.org/10.1007/s11277-021-08582-1. [15] F. Buccafurri, V. de Angelis, S. Lazzaro, Mqtt-a: A broker-bridging p2p architecture to achieve anonymity in mqtt, IEEE Internet of Things Journal 10 (2023) 15443–15463. doi:10.1109/JIOT.2023.3264019. [16] F. Buccafurri, V. D. Angelis, M. Francesca Idone, C. Labrini, Wip: An onion-based routing protocol strengthening anonymity, in: 2021 IEEE 22nd International Symposium on a World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2021, pp. 231–235. doi:10.1109/WoWMoM51794.2021.00041. [17] T. Grube, M. Thummerer, J. Daubert, M. Mühlhäuser, Cover trafic: A trade of anonymity and eficiency, in: Security and Trust Management: 13th International Workshop, STM 2017, Oslo, Norway, September 14–15, 2017, Proceedings 13, Springer, 2017, pp. 213–223. doi:https://doi.org/10.1007/978-3-319-68063-7_15. [18] F. Buccafurri, V. De Angelis, M. F. Idone, C. Labrini, S. Lazzaro, Achieving sender anonymity in tor against the global passive adversary, Applied Sciences 12 (2022). URL: https://www. mdpi.com/2076-3417/12/1/137. doi:10.3390/app12010137. [19] F. Buccafurri, V. De Angelis, M. F. Idone, C. Labrini, A protocol for anonymous short communications in social networks and its application to proximity-based services, Online Social Networks and Media 31 (2022) 100221. URL: https://www.sciencedirect.com/science/article/ pii/S2468696422000258. doi:https://doi.org/10.1016/j.osnem.2022.100221. [20] M. R. Nosouhi, S. Yu, K. Sood, M. Grobler, Hsdc–net: Secure anonymous messaging in online social networks, in: 2019 18th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/13th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE), 2019, pp. 350–357. doi:10. 1109/TrustCom/BigDataSE.2019.00054. [21] G. Danezis, C. Diaz, A Survey of Anonymous Communication Channels, Technical Report MSR-TR-2008-35, 2008. URL: https://www.microsoft.com/en-us/research/publication/