How blockchains support data privacy: Ethereum vs. Everscale [Deep Tech]

This is the third and last article where we analyze Ethereum’s ‘’three transitions’’ (the term coined by Vitalik Buterin in his eponymous article) against Everscale’s tech stack. In the previous two, we dealt with scalability and account abstraction (AA). For the purposes of this article, we are going to be focusing on privacy.

It should be mentioned from the beginning that both networks do not have a ready-made solution ensuring complete data privacy yet. Currently, work is underway to equip both Ethereum and Everscale with such functionality, with two protocols in active development. For Ethereum, it is stealth addresses, while Everscale views zk-SNARKs as the most viable solution.

Before switching to the intricacies of the two protocols, we will start by explaining why data privacy in blockchain is a necessity. Also, to paint the full picture, we will touch on some basics about transaction processing and examine the modus operandi of two existing privacy-enhancing solutions used in the blockchain industry. These are crypto mixers and anonymous blockchains like Monero.

The case for blockchain data privacy

Data privacy does not merely refer to transaction privacy (although we will cover that as well), meaning transferring coins from one wallet to another. Data privacy is actually much broader in scope. It refers to the confidentiality of any data registered on a public blockchain.

The reason being is that blockchain technology has rapidly evolved from a pure cryptocurrency solution to a promising technology with widespread applicability in the heavily regulated enterprise sector. For instance, the General Data Protection Regulation (GDPR) in Europe states that everyone has the right to withdraw their consent at any time and permanently delete any personal data that they have previously shared.

Note: The only difference between private and public blockchains lies in access permission. Private blockchains can be accessed by invitations whereas public blockchains can be accessed by anyone.

Here’s an example. The Patientory blockchain company has created a solution for real-time storing, transferring and accessing patient healthcare data on the PTOYMatrix blockchain. This system provides data interoperability and gives medical professionals access to medical data from various repositories. This is done with the consent of patients.

But what if they suddenly change their minds? This is not consistent with the irreversible recording of information in the blockchain. According to law, EU citizens can legally revoke the right to use such information. Despite the fact that Patientory uses a private blockchain, it is still impossible to erase data if it is already recorded on a blockchain.

Here is another example. The University of Nicosia in Cyprus has become the first educational institution to accept payment of tuition fees for online courses in bitcoin. Interestingly, the first such payment was processed in 2013, at a time when blockchain technology was considered no more than a fad with no prospects of adoption in real sectors of the economy.

Since then, the list of universities accepting crypto payments has expanded. Nowadays, there are dozens of such universities. Moreover, the University of Nicosia went even further. It now provides a solution for storing certificates of course completion on the blockchain. Now graduates can provide anyone with a hash (ID) of their certificates to prove that they successfully completed a course. To prove that the graduate is an actual owner of the certificate, they will have to hash a test message with the private key used to hash the certificate.

This is quite an effective solution, ridding people of the need to exchange files over email or track down transcripts from their universities. However, the construct of most blockchains is such that everything that is entered into it once will remain there forever. For instance, if you share the hash of your diploma with a prospective employer and then later want to prohibit them from viewing this data you will not be able to do so.

The text above leads us to the conclusion that the only way to deal with data management in a compliant way is to make it private.

The animation below highlights the differences between private and non-private transactions.

Blockchain transactions: how public and private keys work

Since each record in a blockchain, be it a transfer of tokens or a record of a medical certificate, is a transaction, let’s see how they work in practice.

At the core of any digital asset is a digital signature algorithm where each user has two keys: one public and one private. This algorithm ensures all transactions processed on a decentralized network are correct without having to resort to any third party. That is, if user A sends a certain amount of tokens to user B, the entire network is sure that user A did indeed send the amount in question.

Transaction information is signed with a private key and the signature can be verified by means of a public key. Both the key and the signature are small sets of bytes. If the signature verification fails, in most cases, it means that the message is forged or damaged. In this case, the initiated transaction is simply reversed.

Each successful transaction within the network is ultimately stored in a block (a sequence of blocks creates a blockchain) that stores detailed information about a set of transactions. The blocks are created by blockchain nodes. They provide the computing power necessary to ensure the functioning of a network.

Prior to a transaction being included in a block of a blockchain, it is verified. The verification logic varies from network to network. For instance, in the bitcoin blockchain there are three criteria to be considered: double spending (checking whether the sender has not spent the funds before), fees (incentives for miners to add transactions in blocks) and size limits of blocks (no more than 1MB).

Basically, it works like this: before a transaction is included in a block, the node first verifies through the blockchain whether the sender’s balance is enough to make such a transaction, then it prioritizes transactions offering more fees and includes them in blocks with some spare space left.

Otherwise, even if the node that is the miner in Proof-of-Work (PoW) networks approves the transaction and there is something wrong with it, the block will be discarded by the rest of the network participants. In the case of PoW networks, mining resources will be wasted, while in Everscale, which is a Proof-of-Stake (PoS) network, the node’s stake will be slashed.

How transactions are processed in the Everscale blockchain using the Threaded Virtual Machine

In Everscale, which is an asynchronous blockchain, transaction validation (verification) and execution processes are much more complex. For the former, there are validators with a twofold task: to propose candidate blocks and to vote on blocks proposed by other validators. Once a certain voting threshold is reached, the proposed block is published on-chain. The latter will be examined in action.

The animation below starts with a smart contract. In this case, it is a user’s crypto wallet address or account (remember, in Everscale everything is a smart contract, even your crypto wallet). The wallet address (smart contract) gets a number of messages, then it processes these messages in the Threaded Virtual Machine (TVM) which changes its state (smart contract properties, in this case the balance).

The execution of the smart contract code creates a transaction, which, along with transactions from other smart contracts in the shard, is put into a shard block. As the smart contract executes its code it can generate outbounding messages (up to 255 at a time) and send them to other smart contracts to initiate the execution of their code.

Blockchain transaction privacy: how private is bitcoin

With bitcoin and most other blockchains, digital asset transactions are made available by means of cryptography. Owning a digital asset means owning a set of keys that total several kilobytes. This is just a small file, thanks to which the crypto wallet application opens the necessary account and allows users to make transfers.

The bitcoin blockchain does not disclose recipient and sender identities. Despite this, it is considered non-anonymous. This is due to transactions being visible to all network participants, as they are included in the blockchain. Namely, each transaction within the bitcoin network can be traced and viewed with the help of blockchain explorers which are available to everyone.

Transaction information includes the addresses involved (sender, receiver), amount, timestamp and other information. This makes transactions in the bitcoin network extremely vulnerable to analysis. Knowing the address or transaction identification (hash), you can see both its source of funds and the addresses to which the funds are sent.

In the animation below, we depict the processing of a transaction on the bitcoin blockchain. You can see how it is signed and verified as well as the way it is included in blocks where the information about it can be viewed by anyone with an internet connection.

Common options to ensure blockchain data privacy

The time has come to answer the question: how does blockchain support data privacy? The easiest option that comes to mind in order to ensure data privacy is that users should receive each payment at a new address. Unlike a bank card, which represents a unique bank account, a crypto wallet can generate an almost unlimited number of addresses. However, this is just a half-measure that does not provide complete privacy, because when analyzing the blockchain, anyone can see all the addresses of wallets from which funds are further sent to.

Mixers, like Tornado Cash mentioned by Vitalik Buterin in his ‘’Three Transitions’’ article, are another option capable of hiding the source of transactions (to a certain extent). They work as follows: a mixer, which is a smart contract, receives some funds from the user, makes a large number of transactions with it, dividing them into smaller and more difficult-to-track pieces, and then sends them back to the user’s other addresses.

Although such a technique can potentially mislead some observers, there are blockchain tracking and analytics services that can potentially detect the real source of funds. Let us explain how this works in practice.

Let’s say Alice wants to make a donation to Anthony (in USDT) to help him pay for his drug addiction treatment without anyone knowing it.

With Tornado Cash, there are several steps before the money can reach Anthony’s wallet address.

First, Alice has to deposit the USDT in Tornado Cash. For this, she sends the USDT and the hash of the secret and nullifier. Let that be 0x563.

The USDT and the hash are kept in a smart contract. The hash will be required for the withdrawal of the USDT deposited in Tornado Cash.

Caution! There is a wrong way to withdraw funds from Tornado Cash. If Anthony provides the secret and nullifier, the Tornado Cash smart contract will be able to verify that there is such a hash in its storage which will deanonymize him.

Why is that?

We know that Alice provided the hash 0x563 to the smart contract. Later, Anthony appears, providing the secret and nullifier, which hashes into 0x563. Since the hash function is a one-way function, this means that the only person who knows the secret and nullifier that hash into 0x563 is Alice. This is how the user’s identity is revealed when withdrawing funds.

The right way to make an anonymous transaction with Tornado Cash

To keep the transaction truly private, Anthony has to prove he knows the secret and nullifier so that the hash (secret, nullifier) finds itself in the Tornado Cash smart contract. He should do it in such a way as not to reveal the secret and nullifier. For this, he sends proof to the smart contract demonstrating he knows the secret and nullifier.

The smart contract, in turn, checks whether the proof is valid. Importantly, the smart contract would not be able to know whether the proof is intended for 0x563 or 0x564 or 0x565, which are also stored in the smart contract. In other words, the proof provided would not reveal the identity of Anthony. This solution is enabled by technology called zk-SNARK (we will discuss it in detail later).

What is the nullifier?

Some hackers may attempt to send the same proof many times to get the USDT (or any other token). Therefore, in order to prevent such an outcome, when Anthony sends the proof for token withdrawal, he will also need to send a hash of the nullifier inside the proof. Thus, the following has to be verified inside zk-SNARK:

That the hash (secret, nullifier) is in the smart contract;

The fact that the hash is from nullifier == hash(nullifier).

After checks are successfully completed, the smart contract will release the USDT and record that the withdrawal of tokens has been made.

The animation below demonstrates how the transaction described above is processed in practice.

The third and more sophisticated option is provided by anonymous blockchains, the most prominent of which is Monero. The main solutions enabling transaction anonymity are ring signatures, ring confidential transactions and stealth addresses to provide anonymity. Thanks to this amalgamation of technologies, Monero achieves a much higher level of privacy compared with that provided by mixers. Analyzing the Monero blockchain, it is impossible to trace the sender, recipient or even the amount transferred.

Monero: key features of the anonymous cryptocurrency, explained

The creation of a Monero account requires three things:

A public address to receive transactions.

A private view key that shows incoming transactions of an account.

A private spend key to send transactions.

The spend key and view key, in turn, are used to create a Monero blockchain address. All this is accomplished by the software and does not need any interaction from the user.

Since the solutions enabling transaction privacy in the Monero blockchain are quite complex, it is better to look at how they work in action.

What are Ring signatures in Monero?

Ring signatures make blockchain transactions untraceable. They utilize account keys and a set of public keys (outputs), which are randomly taken from the blockchain via a complex cryptographic method. Instead of explicitly indicating the source transaction, they enable the inclusion in the signature of a group of random transactions that are not related to a particular transfer. Thus, an outside observer will not be able to guess from which source transaction the coins actually come.

The only thing that is known is that the sender has proved their ownership of one of them. Such mixed transactions are called decoys and their number is determined by the so-called anonymity set. This way, ring signatures ensure that transaction outputs are untraceable.

Ring Confidential Transactions (RingCT) are mechanisms that facilitate the hiding of transaction amounts in the Monero blockchain. Let’s see how it works in the animation below.

Ethereum’s take on transaction privacy

Ethereum sees stealth addresses as the most effective option for tackling the transaction privacy conundrum. The protocol behind them is based on the concept of meta-addresses. It makes hiding transaction recipients possible. With the implementation of stealth addresses, Ethereum will basically replace its usual “one user ~= one address” model with a new address for each new transaction model.

Stealth addresses in Ethereum: key components

Let’s define some terms to better understand everything:

• stealth meta-address — a public key used to compute a stealth address for a given recipient.

• spending key- a private key used to spend funds sent to a stealth address.

• viewing key — a private key used to determine whether the funds sent to a stealth address belong to the recipient who controls the corresponding spending key.

• shared secret — cryptographic data that is only known to the parties involved in a secured communication.

• key blinding mechanism — a pair of algorithms used to combine the shared secret with the root spending key.

How stealth addresses work

Imagine Alice wants to send Bob some Ethereum tokens. Bob values his privacy and does not want the whole world to know that it was he who received the funds. The current construct of most blockchains, however, is based on transparency and makes transaction hiding impossible. Stealth addresses are capable of breaking the established blockchain construct and providing transaction privacy on the recipient side. Let’s see how they actually do it.

For convenience, let’s further call Alice the sender and Bob the receiver.

The recipient generates a usual ethereum address which they provide to the sender. The sender, in turn, performs some computations with it to generate the stealth address. Afterwards, to complete the transaction, the sender has to simultaneously perform two operations: to send the ETH they promised and publish an ephemeral public key on the network. To gain control of the newly generated stealth address, the receiver has to scan the chain and find the ephemeral key. The newly generated stealth address can be managed only by the recipient.

The animation below illustrates the workflow we just discussed.

The shared secret and key blinding

The mechanism of stealth addresses in Ethereum demonstrated above is enabled by two cryptographic algorithms which are required to generate a shared secret. The first uses the sender’s ephemeral key and the receiver’s meta-address while the second uses the receiver’s root spending key and the sender’s ephemeral public key.

Unfortunately, such a mechanism can not rely on a shared secret only. Since there is just a private key generated from the shared secret, it creates a situation in which both sender and receiver will be able to control the address. To avoid this situation, a key blinding mechanism was introduced. It works as follows:

There is a pair of algorithms enabling both the receiver to combine the shared secret with his root spending key and the sender to combine the shared secret with the receiver’s meta-address. The whole thing is realized in a way that allows the sender to generate a stealth address for the receiver and the receiver to generate the spending key for that stealth address. Importantly, the key blinding mechanism does not create any associations between the stealth address and the receiver’s meta-address or between one stealth address and another.

According to Buterin, with some work done on the wallet side, stealth addresses could be implemented right away on Ethereum. However, notwithstanding their advantages on the privacy side, they introduce a significant concern — the difficulty of social recovery. In practice, social recovery will require either the loss of privacy or a delay in the recovery of transactions (Buterin claims it could take two weeks). Later on, as the stealth addresses protocol progresses, the social recovery issue will probably be removed. Most likely, this will require relying on protocols such as Zero-knowledge (ZK) proofs which we will examine next.

Zero-knowledge proofs: Everscale’s take on data privacy

Everscale sees zero-knowledge (ZK) proofs as the most viable solution for enabling privacy in a blockchain network. Simply put, this is a cryptographic technique to prove that you know something without revealing what exactly you know. In the context of digital assets, this can be illustrated, for instance, by checking whether a user has funds for a transfer, while not revealing to other network participants who this user is and how many tokens they have in their wallets.

Let’s consider a classic zk example.

We want to convince a blind person that we can distinguish colors. The blind person (the Verifier) takes two squares: one red and one purple. He raises one of the squares in front of you and asks you to remember its color. Then, he hides both squares behind his back and either shows you the same one or the other one. If you name the color correctly, the Verifier is 50% sure you can indeed distinguish colors. Not 100%, because you might have guessed. Another 10 successful tests follow, which according to the probability theory, gives us a 99.90234% chance the statement is indeed true. This in itself is not sufficient to ensure that a system will always operate smoothly. Therefore, there are twenty more tests, which, if all are passed, provide a probability of 99.99999990686774%.

This is an interactive solution, which, logically, can not be applied to high-load services handling thousands of transactions per second. Therefore, we need a non-interactive and rapid solution, which is provided by zk-SNARKs.

Meaning of the “SNARK” abbreviation in zk-SNARK

Note: zk-SNARKs are not embedded in the Everscale protocol yet. However, work is underway to do so.

We already know what “zk” means. Let’s now see what SNARK stands for:

• Succinct: a zk proof must be verified quickly. Thus, it should be short and easy to verify — no large statement proofs.

• Non-Interactive: The Verifier does not have to interact with the Prover to confirm the zk proof.

• Argument: The proof will confirm the validity of zk encryption and uses limited calculations.

• Knowledge: A proof cannot be constructed without access to a witness (private data needed to prove a claim).

Private data transfers with zk-SNARKs

The protocol consists of three algorithms: generator (G), prover (P), and verifier (V). To send data in blockchain privately, we need to abstract the direct asset transfer and transform it into an interaction with the generator algorithm of the protocol.

The Sender uses a utility function to be sent to the generator algorithm: C(x, w).

The function returns True only if x equals w.

Where:

x is public and is calculated as x=hash(w)

w is private

The function is then sent to the generator algorithm, which is governed by a trusted party.

As the generator accepts function C, it returns two publicly available keys — prover key (pk) and verifier key (vk).

The sender uses the prover algorithm to generate a proof of their making a transfer:

proof = P(pk, x, w)

The proof can be used by the recipient to check that the concealed transaction has been actually finalized.

The recipient uses the verifier algorithm to check the proof of the sender’s transaction:

proof = V(vk, proof, public)

Thus, both parties are sure that the transaction was made without interacting with each other and without revealing any information on the transaction, their addresses or the amount. The transaction is fully concealed as its public part is hashed with the sender’s private key.

Please see in the animation how zk-SNARKs work in practice.

Privacy-enhancing solutions are a powerful upgrade to blockchain protocols. This is. especially the case if they aim to host CBDCs and enterprise-grade business solutions, which fall under heavy government regulation, including the requirement for data privacy. Although zk-SNARKs do require some more complex cryptography compared to the implementation of stealth addresses, they offer considerable gains in terms of scalability, which is of the utmost importance for a blockchain like Everscale with an architecture tailored to accommodate a billion or more users. On top of that, Everscale has all the tools necessary to efficiently embed zk-SNARKs into its core protocol.