Ethereum successfully completed the Istanbul Hardfork, on 8th December 2019. Istanbul is the eight Ethereum hardfork network upgrade, in which specific code changes to the Ethereum Protocol were implemented. These include the use of zero-knowledge privacy technologies such as zk-SNARKs.
When privacy technologies are contemplated, Monero and Zcash are the most prominent DLTs use-cases since they enable completely private transactions. Whilst Monero uses a combination of different techniques, Zcash relies on zk-SNARKs to achieve anonymisation, both may face regulatory issues since in most jurisdictions there may be restrictions to list cryptocurrencies with strong privacy mechanisms on DLT Exchanges. This article will be based on the Maltese regulation, which restricts VFA Exchanges from listing anonymous/private virtual financial assets.
According to the Rule R3-126.96.36.199.2. of Chapter 3 of the Virtual Financial Assets Rulebook effective as of 1st February 2020, one of the supplementary conditions applicable to VFA Exchanges is to restrict virtual financial assets which have inbuilt anonymisation functions from being traded on VFA Exchanges unless the holder and transaction history of the virtual financial asset can be identified.Prior to delving any further into Ethereum and how the Istanbul Hardfork may influence the restriction of Ether, we shall examine how this Rule applies to other well-known privacy virtual financial assets such as Monero and Zcash, for a better understanding of the rationale associated with the inbuilt anonymisation function.
Monero: Privacy by default
Monero is an open-source P2P cryptocurrency with a focus on private and censorship-resistant transactions, being cryptographically private by default. This high standard of anonymity is achieved using two different techniques: Ring Confidential Transactions and Stealth Addresses. As a result, anonymity is going beyond pseudo-anonymity, culminating on complete anonymity.
If the system has an inbuilt anonymisation function by default, which applies to every transaction as the standard, there are hardly any doubts that XMR (Monero’s cryptocurrency) is a virtual financial asset with inbuilt anonymisation functions that do not allow for transaction history traceability, as is depicted in the Transaction Sequence below.
As a result, and in accordance with R3-188.8.131.52.2., XMR shall be restricted from trading on VFA Exchange platforms.
Diagram 1 – Monero Privacy Transaction Sequence
Zcash: Privacy as an option
Even if an indetermined term as inbuilt anonymisation function may be easily delineated when the protocol has anonymization by default, uncertainty prevails, mainly when applied to optional private transactions. Zcash is a privacy-protecting, digital currency with zero-knowledge proofs at its core, which allow transaction data to be validated without revealing information about the amount and the parties involved. The specific zero-knowledge proofs used in this DLT are called zk-SNARKs. In Zcash, addresses are either private (z-Addresses) or transparent (t-Addresses). It is of utmost importance to emphasise that the two types of addresses are interoperable. Funds and data can be transferred freely, between any type of address.
On a Z-to-Z transaction, the transaction is registered on the blockchain, so there is material proof it has occurred and that the fees were paid. However, the addresses, the transaction amount and the memo field are all encrypted and not publicly visible. In essence, it is resolved that there might be an inbuilt anonymisation function on Zcash, depending on the type of addresses used.
From this rationale, we may come to two different conclusions: Firstly, we may consider the privacy mechanisms embedded on the protocol as optional and not as default and, consequently, such mechanisms may not be considered as inbuilt anonymisation functions. Secondly, and the most likely conclusion, is that even if the mechanisms are optional, they still are an integrated function of Zcash, and as such ZEC would be considered an asset with inbuilt anonymisation functions. However, if we consider the second contemplated scenario, we should also take in consideration that R3-184.108.40.206.2. applies unless the holder and transaction history of the virtual financial asset can be identified. This condition may be interpreted in two ways. On the one hand, we may consider the transaction history as the direct transfer from the client’s wallet to the VFA Exchange wallet, which means that if the client transfers ZEC from a t-Address, the transaction history can be identified. On the other hand, we may consider the transaction history as the complete ledger of the ZECs transferred to the VFA Exchange. By definition, the condition supra mentioned cannot be satisfied since the transaction history may be obfuscated at any time, as can be seen in the transaction sequence below.
Diagram 2 – Zcash Optional-Privacy Transaction Sequence
As a result and depending on different interpretations, Zcash may be restricted from trading on VFA Exchange platforms, in accordance with R3-220.127.116.11.2.
Ethereum and the Istanbul Improvement Protocol
As mentioned above, Istanbul Hardfork is currently live and was the 8th Ethereum Hardfork Network Upgrade, in which specific code changes to the Ethereum Protocol were implemented.
As a brief explanation, a network upgrade is essentially a change to the network protocol, adding new rules to improve the system. In Ethereum’s case, these rules are defined technically under the form of Ethereum Improvement Proposals (EIPs). Additionally, a hardfork is a permanent divergence in the blockchain and commonly occurs when the new consensus rules implemented are not fully backwards compatible and have the potential to render some previous transactions invalid, and or/change the existing functionality of deployed contracts. As a result, non-upgraded nodes cannot validate blocks created by upgraded nodes that follow newer consensus rules.
Istanbul Meta (EIP1679) is a list of the protocol changes which have been included in the Instanbul Hardfork. In the meta-EIP, six different EIPs were included, such as EIP152, EIP1108, EIP1344, EIP1884, EIP2028 and EIP2200. The EIPs mentioned align the costs of opcodes with their computational costs and improve denial-of-service attack resilience, make Layer-2 solutions based on SNARKs and STARKs more performant, enable Ethereum and Zcash to interoperate, and allow contracts to introduce more creative functions.For this article’s purpose, we will primarily take in consideration EIP152, which adds the ability to verify the Equihash PoW within an Ethereum contract. Consequently, it enables relay and atomic swap transactions between Zcash and Ethereum. Additionally, it is also worth analysing how EIP1108 and EIP2028 may affect Ether regarding the Rule, due to their enhanced privacy enabling technology.
EIP152: Privacy by Atomic Swap Transaction
EIP152 enables the BLAKE2b hash function and other higher variants to run cheaply on the EVM, allowing easier interoperability between Ethereum and Zcash as well as other Equihash-based PoW coins. This interoperability with Zcash enables trustless atomic swaps between Ethereum and Zcash, which provides an aspect of privacy to the public Ethereum blockchain.An atomic swap is a smart contract technology that allows for the exchange of different cryptocurrencies without relying on a third-party. In order to enable atomic swaps, both blockchains should support smart contracts which allow a time-verify(TimeLock), a hash function verify (HashLock) and a visible hash input (Public Pre-Image).
Initially, an atomic swap per se seems an efficient mechanism sufficient to obfuscate the trace of the transaction between two parties. However, it may be a misconception since the same hashSecret (Public Pre-image) will be visible on both blockchains. As a result, it is possible to trace values exchanged between different blockchains.
In an atomic swap between a public and a private blockchain, such as Ethereum and Zcash, the scenario might change considerably. For example, if User A wants to send X Ethers to User B, without being traced, both parties can rely on atomic- swaps with other unrelated Users (C and D) to ensure a layer of privacy. The way it might be done is shown in the Transaction Sequence below; even if the hashSecret (hS) of the atomic swaps between User A and C and User B and D are public and enables traceability between blockchain transactions, as soon as User A and user B execute a Z-to-Z transaction, the transaction sequence is obfuscated; thus the intended transaction from User A to User B is completely anonymous.
Diagram 3 – A Trustless Atomic-Swap Transaction Sequence with a focus on Privacy
From this rationale, the discussion arises on whether the interpretation of the precompiled contract, which enables the BLKE2 F compression function, should be considered an inbuilt anonymization function. Even though it may be considered an “inbuilt mechanism” and a tool that allows indirect private Ether transactions, it seems farfetched to determine such a function as an anonymization tool. The function itself enables atomic swaps between Ethereum and Zcash, which as we previously mentioned are easily traceable. Therefore, the function should not be considered an inbuilt anonymization function, as it requires other functions and transactions to enable complete anonymization. It is possible to conclude that R3-18.104.22.168.2 does not apply to Ether transferred via atomic swaps, and as such, a Licence Holder is not required to restrict Ether from being traded on their corresponding platform.
EIP1108 and EIP2028: Privacy through Layer-2 anonymisation protocols?
Even though there are is a multitude of Layer-2 privacy and scaling solutions, such as Plasma or Azure Protocol, for simplicity reasons we will be referring to zk-Rollup as the standard Layer-2 privacy solution for Ethereum in this article.
Zk-Rollup is a Layer-2 scaling solution similar to Plasma, in which a single mainchain contract holds all funds and a succinct cryptographic commitment to a larger “sidechain” state (usually a Merkle tree of accounts, balances and their states). The sidechain state is maintained by users and operators off-chain, without reliance on Layer-1 storage. This solution applies to ERC-20 tokens as well.
The current zk-Rollup protocol state-of-art provides an efficient solution to scaling and stability by reducing transaction fees and increasing the transaction speed at the cost of a higher commitment latency. The current solution does not support fully anonymous transactions such as Z-to-Z address transactions. The reason being the storage model used on zk-Rollup, which permits privacy on the amount of the Ether or the ERC-20 transferred but does not keep the addresses private. However, it is possible to apply an extra layer of privacy within the zk-Rollup (zk zk-Rollup), which would support a mini version of Zcash within the protocol. We may conclude that the rationale behind the EIPs supra mentioned is to enable more efficient implementations of such Layer-2 solutions on the Ethereum network.
Objectively, the question that needs to be answered is whether the improvements implemented on the Ethereum protocol support Layer-2 potential privacy protocols and thus whether such may be considered an inbuilt anonymisation function.
From a logical perspective, Layer-2 solutions are “built-upon” the Layer-1, and, at the moment, there is no privacy function directly implemented on the Ethereum Protocol. As previously referred, EIP1108 and EIP2028 provide a cheaper and more efficient implementation for privacy protocols and scaling solutions built on top of Ethereum. However, these EIPs are not Ethereum privacy-enablers by themselves. Consequently, even though a Transaction Sequence similar to the one depicted below may happen, R3-22.214.171.124.2 does not apply to Ether and ERC-20 tokens transferred on Layer-2 protocols. Moreover, a Licence Holder is not required to restrict these DLT Assets from being traded on their corresponding platform.
Diagram 4 – A zk zk-Rollup Private Transaction Sequence
Conclusion: Istanbul Hardfork Threat
The term inbuilt anonymization protocol, as mentioned in R3-126.96.36.199.2, may be subject to different interpretations. For this article, we took the literal approach, where a virtual financial asset has an inbuilt anonymization protocol if there are any anonymization mechanisms embedded on the primary protocol.
From this interpretation, we came to the conclusion that Monero (XMR) clearly falls under the term for its special anonymization features. Zcash (ZEC) is more complex to interpret since there are mechanisms embedded in the primary protocol that admittedly allow privacy, but are merely optional. By not being by default, Zcash raises some doubts on the inbuilt understanding.The Istanbul network update has integrated functions that enhance privacy on the Ethereum Blockchain. However, such functions are not anonymization tools per se and could easily obfuscate the trace of a transaction within the primary protocol; as a result, VFA Exchanges do not need to restrict their platforms from listing Ether or ERC-20 tokens.
This article does not purport to give legal, financial or tax advice and the intended use of this article is deemed to be for general information purposes only. Should you require further information or legal assistance, please do not hesitate to contact Guilherme Maia.