Introducing the Shielding Demo and zkOS on Testnet!

zkOS development is progressing rapidly! Here’s a showcase of one of the key capabilities of Aleph Zero’s privacy—the Shielding Demo —and a breakdown of how it works.

Looking at zkOS progress thus far

It’s best to think of zkOS as the engine that enables the privacy inherent within Aleph Zero to run. zkOS is an absolutely crucial element of the whole platform. But at the same time, the work done on zkOS is often about low-level cryptography features and heavy optimization.

Thus, it is not an easy task to fully explain its impact. This time, in conjunction with the overall progress update on zkOS, we have a detailed showcase of one of the key advancements that zkOS has achieved—the Shielding Demo.

But first, let’s look at the advancements within zkOS that have made the Shielding Demo possible:

1. Efficient on-chain cryptography: since SNARKs require custom cryptographic primitives available on-chain, zkOS provides heavily-optimized contracts that minimize the gas consumption—making transaction fees low for end-users;

2. Subsecond client-side ZK proving: what’s the difference between client and server-side proving? Server-side proving involves computations done by an external party, while client-side proving allows an end-user to compute zk-SNARK proofs on their own device efficiently—thus enabling privacy without compromising UX;

3. Shielded pool primitive: a feature that allows the user to “hide” their tokens. This is what our showcase—the Shielding Demo—is all about! So, let’s dive in.

Introducing the Shielding Demo: Rapidly shielding your tokens and achieving total on-chain privacy in the process

The Shielding Demo is the most basic privacy function made possible by zkOS: “hiding” or shielding your tokens. It is a simple web-app that you can use to keep your TZERO (AZERO on EVM testnet) private. For a full video tutorial on how you can use it, click here. 

We need to clarify that the Shielding Demo is a Testnet-only deployment at the moment. But as we rapidly progress to Mainnet, shielding will be natively integrated within the Common app—where as much of the technical intricacies as possible will be hidden from the user. For now, you can treat this as an opportunity to better learn the zkOS system and how it is used in applications that are built on top of it.

The magic of shielding. How does it really work?

In the simplest possible terms, the shielding functionality is a regular smart contract on Aleph Zero EVM Testnet, however the things it can do are quite extraordinary. In fact, to explain it without using mathematical terms, we’ll need to resort to magic. 

The best way to imagine the Shielding Demo is to see it as a magic vault on the blockchain. Every user can deposit funds into this magic vault—this is referred to as the “Shield” operation in the web-app. While this interaction with the contract may seem ordinary, there is actually some smooth magic going on behind the scenes (a zero-knowledge proof is attached to the transaction).

Injecting secret data into a public chain

It works like this: a user sending 10 AZERO to the vault attaches a secret password to this deposit that will later allow them to claim the tokens. This password, along with the deposit value is stored within the magic vault, such that:

• No external party (other users of Aleph Zero) can see what the password is. Note how unique this is—the user is able to inject secret data into a public chain!
• Anybody who comes to the vault and inputs the correct password for this deposit can claim the 10 AZERO. But it’s important to note here that no external party is able to tell when the corresponding deposit took place.

The basic usage of the magic vault could be described as follows: Alice deposits AZERO to the vault (possibly in multiple batches, setting different passwords) and then at any point in time, she can withdraw any portion of the deposited AZERO to a fresh blockchain account (by entering the password to the vault). From the viewpoint of an external observer, the party who deposited the AZERO to the vault is not able to be linked to the party who made the withdrawal. This is thanks to the magic (or zk-SNARK math, depending on how we want to view it) that allows the vault to keep the password secret. 

Within the Shielding Demo, this operation is called Private Send. Here’s what a Private Send operation looks like practice. Alice sends tokens from the magic vault to any (but likely a new, unrelated) account. Note that this primitive enables complete on-chain privacy for Alice! Nobody is able to view Alice’s full account history if her interactions with the chain are not able to be linked to her (on any public blockchain, all of her activity would be visible and traceable to her).

Relayers: achieving private account abstraction

An attentive reader might spot a subtle gap in the reasoning above. For Alice to withdraw the AZERO to a fresh account, she needs to top it up with gas tokens (it’s impossible to send a transaction from an empty account). However, this would involve Alice sending AZERO to this fresh account, which would then be linked to her previous account. This is exactly what we wanted to avoid! 

This issue is resolved by making use of relayers (you will see relayers mentioned in the Shielding Demo), which are special parties to whom users delegate the execution of the magic vault withdrawals. It is worth noting that the role of relayers is fully trustless, and users don’t compromise security or privacy when using them. Readers familiar with the notion of account abstraction might also note that this feature looks similar to ERC-4337—and rightfully so—it allows for the anonymous execution of shielded transactions. It is also important to note that it is possible to completely opt-out from using relayers.

We should mention that while the magic vault metaphor provides an intuitive explanation of how the Shielding Demo works, it is not a completely accurate description of this functionality. In particular, when withdrawing funds, the user does not literally “input” their password. This would make it public—and hence—introduce multiple new issues (for instance, someone could try to steal the funds by front-running). In reality, the user merely proves their knowledge of the password, and more formally, creates a zero-knowledge proof of knowledge of a secret trapdoor to send along the appropriate transaction.

Try the Shielding Demo out right now!

We encourage you to try the Shielding Demo out right now. We are trying to gather as much feedback as possible—especially concerning the proving time on different browsers and operating systems (including mobile devices). We’re also planning some incentives for Shielding Demo testers that help us in collecting data about real-world performance—so start testing now and watch out for further announcements. 

How can you stay totally private? Key preventative measures you can take in conjunction with the Shielding Demo

Some of the other main reasons for releasing the Shielding Demo is to spread knowledge on how shielding works, what the particularly recommended use patterns are, and what should be avoided. To illustrate these points, consider the following scenario:

1. Alice deposits 17.2 AZERO to the Shielding smart contract from account A1;

2. She then immediately withdraws the 17.2 AZERO from the Shielding contract to account A1.

From the viewpoint of an external observer, it is visible that somebody deposited 17.2 AZERO to the Shielding contract from account A1—and that immediately after—somebody withdrew the same amount to the same account. Thus, even though it is not possible to prove that both these actions are linked to each other (made by the same user), it is quite obvious that this is the case, because:

• Both actions involve the same account (A1);
• They happened at roughly the same time;
• The weirdly specific amount of 17.2 appears in both actions.

Using a fresh address, spreading deposits over time, and depositing and withdrawing common amounts

Indeed, all of the above events and details can be used to track users, even if they are routing their tokens through a shielded pool. The following preventive measures are thus recommended when using a shielded pool:

1. Whenever you withdraw tokens from a shielded pool, ideally do so from a fresh blockchain address;

2. Spread your deposit and withdraw actions across time. Ideally, keep all your funds deposited in the shielded pool at all times—and only withdraw when you want to use them;

3. Be careful about specific amounts when depositing and withdrawing. Ideally, use round values, such as 10, 20, 50, 100, etc., so that you can better hide among other interactions within the pool.

4. Sometimes it’s easy to forget that there are so many traps that users can fall into when utilizing a shielded pool! This is why we’re building the Common app with native shielding. The Common app takes care of all the privacy hygiene for the user—and makes the experience of interacting with the blockchain privately completely seamless.

The Common app and zkOS—the next steps

In building the Common app, the team is working hard on delivering an unprecedented solution that natively supports privacy via shielded pools, along with ensuring interchain capabilities across all major EVM networks, which will enable users to make their tokens private on all supported chains. 

It is absolutely essential for us to deliver a product that is as user friendly as possible. This is precisely why we’re developing a fraud prevention feature within zkOS that protects shielded pools from bad actors that may attempt to exploit them and route their illicit funds through them privately to different accounts. 

For more details on the Shielding Demo, check out the shielder section on the Aleph Zero docs site.

Plus, don’t forget to test out how fast and smooth the Shielding Demo is.