zkFi: Privacy-Preserving and Regulation Compliant Transactions using Zero Knowledge Proofs
June 2023

ZCash blockchain was among the first to tackle privacy by facilitating anonymous transactions. While innovations there have been impressive, they could not reach the intended adoption nor offered any programmability - restricting only to peer-to-peer transactions. Hence, missing out on the prominent application level use-case for, eg. DeFi. Monero, another private chain, more or less shares the same context.

Tornado protocol on Ethereum amassed a significant number of usage despite not-so-good UX. But it overlooked compliance and became go-to-place for money laundering (trm-labs, ). A portion of its volume has ties to large-scale hacks (Chainalysis, ), attracting serious implications from regulators. It, too, only offered peer-to-peer private transactions lacking any interoperability beyond that. Aztec came up with a novel solution with their L2 roll-up approach that had DeFi compatibility to some extent. However, it required users to bridge their assets back and forth and had significant waiting times - making it not-so-practical for all kinds of DeFi interaction, e.g. in swaps because of slippage.

Others also share the same problems, especially weak compliance guarantees and friction in user experiences.

zkFi uses ZKPs to facilitate privacy at its core by achieving the following goals:

• •

  Performing private transactions concealing sender, recipient, and amount of funds being transferred.

• •

  Ensuring transactions cannot be linked together, preventing tracking the flow of funds.

• •

  Preventing double-spending by proving the transaction is valid without revealing information about the transaction itself.

• •

  Selective de-anonymization by ensuring verifiable encryption of transaction data.

While there are multiple formulations of ZKP systems available and being researched, zkFi specifically utilizes a groth16 (groth16, ) zkSNARK system which is currently most suitable for on-chain privacy applications.

Compliance has been the conundrum for privacy protocols so far. zkFi aims to have an industry-standard compliance framework such as:

• •

  Selective De-Anonymization: For an industry-standard AML practice, a process for the de-anonymization of user-specific private transaction data needs to be followed. It could be a voluntary de-anonymization where the entity in question can share general or per-transaction viewing key to a regulatory authority. In other cases (for malicious actors), involuntary de-anonymization may be enforced in response to a regulatory emergency or court order. The latter is an accountable multi-party process to prevent abuse of power. It is thoroughly studied in (compliance-sol, ) as SeDe (short for Selective De-anonymization) framework for compliance and is a flagship among all compliance tools available.

• •

  Deposit Limits: We put a fiat limit on the asset being transacted and/or the volume flowing through the protocol in a time period. There can be a provision to relax this limit for specific entities like a compliant businesses.

• •

  Risk Management and Screening The protocol sets up compliance and risk management integrations to identify and prevent any kind of illegal financial activity. This could be achieved by services like TRM Labs¹¹1https://www.trmlabs.com/ products and Chainalysis²²2https://go.chainalysis.com/chainalysis-oracle-docs.html oracles perform screening and identifying inflow of illegal funds into the system.

By offering an SDK, a full set of compliant privacy features is instantly available to protocols and their developers. SDK facilitates a simple composable plug-and-play solution that abstracts away every bit of ZKPs or compliance-specific complexities. This renders immense benefits to protocols such as:

• •

  New protocols can focus on developing their core features without investing time and resources into ZK development.

• •

  Existing protocols do not have to modify their smart contracts for compatibility. It’s a simple plug-and-play through SDK.

• •

  Compliance issues often come as part of a privacy conundrum. But with zkFi, protocols will not have the burden of juggling privacy-related compliance practices.

In addition to the advantages mentioned above, the flexibility of interaction with the integrating protocol remains at the hands of a developer. Given private user assets and/or data as input, developers are free to write any custom logic to apply to the inputs.

See section 6.4 for implementation details.

The advent of EIP-4337 (eip-4337, ) Account Abstraction proposal allowed for significant improvements in user experience across protocols. One such improvement or feature it brings is the ability for smart contracts to pay for gas fees of transactions. This allows for gas-sponsored transactions or payment of gas fees in ERC-20 tokens.

In privacy protocols, there exists a common problem referred to as gas dilemma or fee payment dilemma. A gas dilemma exists because if users need to pay the gas fees from their wallet to execute their transactions then this gas payment discloses the user’s public profile since their address as the sender of the transaction is now visible publicly.

zkFi uses account abstraction features from EIP-4337 so that the gas fee can be paid in ERC-20 tokens making transactions on zkFi a smooth experience. The flexibility of gas payment is left to the integrating protocol - allowing it to sponsor transaction fees or charge from their users in any desired way. In the case of peer-to-peer transactions, a user simply pays gas in transacting assets. This is facilitated through a custom EIP-4337 Paymaster contract that pays the gas on the user’s behalf in exchange for a small fee in any supported asset.

By implementing a simple interface, provided within SDK, for the shielded account operations (e.g. signing private transactions), crypto wallet applications can support private transactions for their users. In that case, the shielded account keys share the same security space as the wallet’s private keys. Developers simply send defined requests to the shielded account for, say, authorizing transactions by signing it. This allows developers to directly use the shielded account in their application UIs without concern about securely handling sensitive keys.

Some examples of such wallet integrations are:

• •

  MetaMask: MetaMask is a browser extension as a crypto wallet. Through its Snaps API (mm-snaps, ) it allows developers to extend its functionality by publishing custom packages of logic called ”Snap”. One such Snap, the ”zkFi Snap” acts as an interface to the shielded accounts within MetaMask.

• •

  Ledger: Ledger is a hardware wallet that securely stores private keys for multiple cryptocurrencies. It allows Embedded Apps (ledger-apps, ) to be installed on the user’s device. A zkFi app is one such app tailored to securely store shielded account keys and authorize private transactions from the device.

A user holding a shielded account can sign valid transactions and decrypt balances and transaction data. Unlike normal Ethereum accounts which are controlled by a single private key, a shielded account contains two types of such keys.

We assume the existence of a cryptographically secure random number generator (RNG) function used to generate private keys:

We cryptographically derive the keys of the shielded account using the $\mathtt{poseidon}$ hash function (from 25) and group operations on the BabyJubJub curve (see Sec. 7.2).

A stealth address is a one-time address that is randomly generated to receive funds to. This address is not linked to the receiver’s permanent address. Hence making it difficult to link or track a particular user’s transactions and protect their identity.

There are multiple different schemes available for deriving a stealth address from a user account. These schemes allow the receiver to detect funded stealth addresses meant for them and calculate the associated private key from auxiliary data, normally sent along with the transaction. The calculated private key can then be used to sign transactions authorizing the spending of funds at that stealth address. One example of such a scheme is defined in EIP-5564 (eip-5564, ).

In zkFi, we primarily use ZK proofs (but also signatures) for constructing valid transactions. This allows for a much simpler and more efficient way to generate and use stealth addresses in the protocol. A zkFi stealth address, $x$ is derived from sign public key $S$ as:

where $\delta$ is a random element also referred to as a blinding factor.

To relay any auxiliary data to be included in the transaction request, the sender generates an ephemeral public key, $Q=r\cdot G$ where $r\in\mathbb{B}^{248}$ is another random element.

A sender then calculates a shared key $K$ from the view public key $P$ of the receiver as:

$K$ is used to encrypt any desired sensitive transaction data, e.g. $\delta$, to get a ciphertext, $C$.

A view tag, $t$ for this stealth address or transaction is the most significant byte of the hash of $K$:

$t$, $x$, $Q$ and $C$ are concatenated to form auxiliary data $(t\|x\|Q\|C)$ to be broadcasted along with the transaction.

A user parses the auxiliary data of a transaction and tries to calculate a shared key $K^{\prime}$ using its view private key $p^{\prime}$ and $Q$ as:

And calculates a view tag $v^{\prime}$ from $K^{\prime}$ using equation 8. If $v^{\prime}\neq v$, the user is not the receiver. It stops.

Otherwise, the receiver continues and uses $K^{\prime}$ to perform decryption of $C$ to retrieve the plaintext data, e.g. $\delta^{\prime}$, that was encrypted before. The receiver uses $\delta^{\prime}$ to calculate the stealth address $x^{\prime}$ (using equation 6). The user performs an additional check that $x^{\prime}=x$ (hence, $\delta^{\prime}=\delta$) to be sure that it is indeed the receiver just in case the view tag match was a false positive.

To spend the asset the receiver is now able to prove a statement $\mathcal{S}_{x}$ defined as:

The proof of $\mathcal{S}_{x}$ is included in the ZK proof $\boldsymbol{\pi}$ of the transaction to prove the ownership of $x$.

Core smart contracts of the zkFi protocol. The core includes a multi-transactional multi-asset pool, meaning the pool supports multiple assets and can transact multiple assets in a single transaction. The on-chain ZK Verifier verifies the proof submitted during the transaction.

A Protocol Proxy is a state-less contract that lives on-chain to act as a proxy for a target (e.g. DeFi) protocol. This contract must implement a standard interface that exposes a ”convert” functionality or operation. This reflects the fact that, in general, any DeFi operation e.g. swapping, lending, staking, can be thought of as a process of converting from one asset called input asset to another asset called output asset. Here are a few examples:

• •

  When swapping ETH for USDC on Uniswap, ETH (input asset) is converted to USDC (output asset).

• •

  When supplying DAI on the Aave market to earn interest, DAI (input asset) is essentially being converted to aDAI (output asset) the interest-bearing tokens given back in return.

• •

  Staking ETH (input asset) on Lido results in conversion to stETH (output asset) holding which represents your stake plus rewards.

This allows Core the core to interact with protocols via a Convertor contract. In its convert operation, this proxy is supposed to perform necessary operations by calling the target it is the proxy for, eventually returning any output to the Core.

It is a specific kind of transaction where $V$ values are set to non-zero so that these values, $\mathbf{v}$ are sent as input asset (with ids $\mathbf{e}$) if required. A fee asset of id $e_{f}$ and value $v_{f}$ is also given specifying gas fee requirements. Fee must be paid by returning it as one of the output assets. The target protocol may chose to pay gas however it wants. Lastly, the input also includes an arbitrary payload, $d$ necessary for operation by the proxy. After processing the input, $(\mathbf{e},\mathbf{v},e_{f},v_{f},d)$ with its specific target protocol, the proxy is expected to return output asset $(\mathbf{e}^{\prime},\mathbf{v}^{\prime})$.

Later, a note commitment is calculated with $(e^{\prime},v^{\prime})$ for each of $m$ outputs and a given stealth address as a transaction parameter and inserted into $\mathcal{T}$.

The flexibility comes from the fact that the implementation of $\mathtt{Convert}$ is left to the developer trying to integrate the target protocol.

zkFi adopts a framework for involuntary de-anonymization of illicit transaction subgraphs using a threshold multi-party procedure while keeping such parties accountable.

The process involves an independent set of parties called guardians. Each of the $n$ guardians holds a share of the secret key which decrypts encrypted transaction data such that guardians must reach a quorum of minimum size $t$ ($t\leq n$) for the de-anonymization of any transaction to occur. However, even after de-anonymization is granted by guardians, they still do not learn any information about the user because another decryption still needs to be performed by an individual party called the revoker.

Accountability comes from the fact that the revoker is bound to send a publicly verifiable request of de-anonymization to the guardians who must agree first for the revoker to extract any information at all. A more detailed study can be found in (compliance-sol, ).

A hash function is a mathematical function, $h$ that takes arbitrary length input, $m\in\mathbb{B}^{*}$, and outputs fixed-length output $x\in\mathbb{B}^{n}$ often called hash, hash value or digest.

A cryptographically secure hash function has the following properties:

• •

  Pre-image resistance Given a hash value, it must be difficult to find the input that produced it.

• •

  Second pre-image resistance Given an input and its hash value it must be difficult to find another input that produces the same hash.

• •

  Collision resistance It must be difficult to find two inputs that map to the same hash value.

Specifically for its ZK-related operations, zkFi extensively uses a hash function called Poseidon (poseidon, ) denoted as $\mathtt{poseidon}$:

A common in the Ethereum ecosystem is the Keccak256 (keccak256, ). It is used within zkFi where it does not require proving via ZK proof. It is defined as:

Elliptic curves are mathematical structures that are defined over some finite field that have interesting properties that make them very useful in cryptography. The security of ECC relies on the computational infeasibility of solving the elliptic curve discrete logarithm problem (DLP) (dlp, ).

Let $E$ be an elliptic curve defined over a finite field $\mathbb{F}_{q}$ where $q$ is a large prime number, and let $P$, $Q$ and $R$ be points on $E$. The elliptic curve group operation on $E$ is typically denoted as $P+Q$, where $P+Q+R$ satisfies the group law:

where $\mathcal{O}$ represents the point at infinity.

The elliptic curve DLP is defined as finding an integer $k$ such that $S=k\cdot P$, where $k\cdot P=P+P+....+P$ ($k$ times) is referred to as scaler multiplication of point $P$.

A cyclic subgroup is a subset of an elliptic curve group that is generated by a single point called generator, denoted by $G$. Elements of the subgroup are obtained when $G$ is scalar multiplied by integers i.e. $k\cdot G$ where $k\in\mathbb{Z}$.

zkFi protocol uses a specific elliptic curve called Baby JubJub as defined in (eip-2494, ). It is particularly well-suited for cryptography operations in zero-knowledge (ZK) applications.

A digital signature $\sigma$ is a verifiable piece of data produced by signing a message $m$ with a private key $s$ through some chosen signature scheme or function.

The signature scheme can later verify that the signature $\sigma$ was produced by an entity who knows the $m$ as well as private key $s$:

where $P$ is public key corresponding to $s$ and $y$ is a single bit representing result of verification - $true$ or $false$.

A cryptographically secure signature scheme must have the following properties:

• •

  Authenticity A valid signature implies that the message was deliberately signed by the signer only.

• •

  Unforgeability Only the signer can produce a valid signature for the associated message.

• •

  Non-reusability The signature of a message cannot be used on another message.

• •

  Non-repudiation The signer of the message cannot deny having signed the message with a valid signature.

• •

  Integrity Ensures that the contents of the message are not altered.

zkFi utilizes Schnorr (schnorr, ) signature scheme for signing private transactions and verifying those signatures. The signing function is defined as:

and verification as:

where $b$ is a single bit representing result of verification $true$ or $false$.

Zero-knowledge proof (ZKP) is a cryptographic technique that allows a party, a prover to prove to another party, a verifier that it knows a secret without actually revealing a secret by following a set of complex mathematical operations.

Although the origins of ZKPs can be traced back to the early 1980s, when a group of researchers, including Shafi Goldwasser, Silvio Micali, and Charles Rackoff, published a paper (zkp, ) that introduced the primitive concept to the world, it lacked practicality at the time. However, later developments addressed the problems leading to usable implementations in various systems, especially with the advent of blockchains.

In order to be ZKP, it must satisfy three properties:

• •

  Completeness: If the statement is true, both the prover and verifier are following the protocol, then the verifier will accept the proof.

• •

  Soundness: If the statement is false, no prover can convince the verifier that it is true with any significant probability.

• •

  Zero Knowledge: If a statement is true, the verifier learns nothing other than the fact that the statement is true.

One particularly efficient type of ZKP is zkSNARK. A SNARK (Succinct Non-Interactive Argument of Knowledge) defines a practical proof system where the proof is succinct that can be verified in a short time and is of small size. The system is non-interactive so that the prover and verifier do not have to interact over multiple rounds. Knowledge refers to the fact that the statement is true and the prover knows a secret, also called “witness” that establishes that fact. If a SNARK proof allows for proof verification without revealing a witness it becomes a zkSNARK.

Generating a zkSNARK proof is a multi-step process that involves breaking down logic to primitive operations like addition and multiplication, creating an Arithmetic Circuit consisting of gates and wires. This circuit is then converted to a R1CS (Rank-1 Constraint System) which constrains the circuit to verify, for instance, that values are being calculated correctly with gates. The next step converts these constraints in the circuit to a Quadratic Arithmetic Program (QAP). QAP represents these constraints with polynomials rather than numbers. Afterward, together with Elliptic Curve Cryptographic (ECC) and QAP, a zkSNARK proof is formed.

Merkle Tree is a data structure that is used to store and verify the integrity of data. It is a binary tree where each node has two children. The leaves of the tree are the data blocks that are stored and the internal nodes of the tree are the hashes of children below them. Consequently, the root of the tree is the culmination of all data blocks in the tree. This means that if any data blocks at the leaf nodes are changed or corrupted it will propagate to the root which will change too.

The root hash of the Merkle tree can be compared to a reference to verify the integrity of the data. This makes the Merkle trees very efficient.

A merkle tree is maintained in zkFi to record user assets. User-deposited assets are represented in the form of a hash called commitment that gets stored in a Merkle tree structure. During withdrawal, the same user submits a proof a.k.a Merkle Proof (among others) of inclusion of the same commitment hash in the tree and proof of knowledge of the hash’s pre-image, without revealing any traceable information like an index of commitment in tree or constituents of pre-image.