Zero Knowledge Proof & Privacy Development on Solana
Blockchains have been built upon the notion of transparency, where participants are actively involved in verifying transaction values within the peer-to-peer network. In the rules of cryptography, “don't trust, verify” has always been the mantra, and the permissionlessness nature of the network allows for data to be seen publicly.
The system’s open nature means malicious parties can be easily identified and pressured, thus minimizing centralization risks. It also means that wallets and user transaction records are publicly available information by default. In a world where censorship resistance is valued, blockchain becoming a tool for surveillance is a detriment to the ethos of the technology and should be mitigated heavily. But how to increase transparency (for dominant forces/ entities) while preserving sovereignty for the individual? The answer is through the use of zero-knowledge proof.
In this essay, we will cover the basics of zero-knowledge proof, its relevance to blockchain development, and the work being done to bring privacy to Solana.
What is zero-knowledge proof:
The proof is a statement that can be verified to be true. Zero-knowledge means that the proof needs no outside information to verify its legitimacy. Together, we have zero-knowledge proof, a statement that can be verified while avoid conveying any further information beyond the mere fact of the statement’s truth.
In essence, zero-knowledge proof (ZKP) is a cryptographic method that allows one party to prove to another party that the validated data is correct without revealing the data itself. Financial verification is a use case where ZKP can be implemented.
Imagine you are applying for a visa, and during the process, you have to prove your financial status and that you have enough money to cover your expenses during your time abroad.
In the current world order, this process will require visa applicants to submit a copy of the following:
their bank statements,
a list of assets under management,
and any other evidence that shows eligible financial status.
You will also have to trust that these companies/organizations will not publicize your private information, due to the regulation in place. This is a trusted set-up where you believe the counterparty will remain honest, and not leak personal/private info
With ZKP, you can limit the amount of personal information that can be leaked throughout the process. Instead of revealing personal information, you will only be required to produce “proof” of your financial status, that you have sufficient financial means to satisfy the visa requirements.
Other private information, such as how much of the account is liquid, the current values of the managing assets, or any additional propriety information, can be omitted from the verification process. This means better privacy for your information, while still ensuring the validity of the information processing that takes place.
How ZKP works:
In a ZKP system, there are two major parties: Prover and Verifier. As the names suggest, provers help create a proof of knowledge of the hidden information, and verifiers testify to the legitimacy of the proof. The process requires computation resources on both the prover and the verifier. The construction can be visualized below, with several components:
Witness: as discussed above, the prover wants to prove knowledge of hidden information. The assumption here is that only the prover with knowledge of the hidden info can answer the questions established by the prover. The prover then selects these questions at random, calculates the answer, and sends it to the verifier
Challenge: The verifier randomly picks another question from the set and asks the prover to answer it.
Response: Prover will receive the question, calculate the answer, and send it to the Verifier. This response allows Verifier to check if Prover has actually accessed the witness. To make sure Prover doesn’t rely on luck, Verifier will ask a variety of questions. By repeatedly interacting, the ability of faking knowledge of the witness is significantly reduced until Verifier is satisfied.
Interesting properties emerge from this system, in the context of blockchain:
The construction and the nature of Zero Knowledge Proofs provide some very interesting phenomena that can be utilized within the blockchain context:
Privacy:
By only producing a “proof” of a transaction, other information about the state of the transaction can be omitted and not available through a blockchain explorer or a data query, depending on the specific implementations. These include but are not limited to, the total amount being sent, the token type, the sender address, and the recipient address of the transaction.
The transaction is still recorded on the public blockchain ledger, but the information which allows for wallet tracking and traceability is removed from the equation, providing true privacy and sovereignty to the individual users.
Data compression/scalability via succinctness:
Another property of zero-knowledge proof is its succinctness, which enables scalability. Instead of executing the entire transaction/ transaction batch to confirm its validity, the system only needs to verify the proof of these sequences, and as such, reduce the data requirements for processing, as well as gas fees.
Zero-knowledge proof means that a true statement is verifiable, and as a result, allows for an aggregated proof of proof to be verified by the settlement layer. This means that large-scale verifications can be reduced down to the verification of a single proof, and as such, offer a proof size with better verification time than the normal verification method.
For most zk-rollups on Ethereum, the scalability provided by zero-knowledge proof is the main driver for production and implementation today. By outsourcing computation/execution to L2s, and only doing verification of proofs, Ethereum can now scale with cheap txn on L2s, due to its own computational constraints.
It’s also important to understand that zk-rollups in their current form have to make trade-offs between privacy and scaling/composability, given the inefficiency in system design. As Torgul Maharramov, a senior cryptography researcher at Scroll (an Ethereum L2 project) discussed on the Validated Podcast.
Right now it’s basically disintermediated from one another. If you are doing privacy its dificult to do complex computation without blowing up the complexity of your protocol, and as a result, blowing up the complexity of the proof you are computing.
Either you have privacy and limited functionality, or you have to use it for scaling but with better functionality and flexibility in terms of usage and build.
With our basis covered with zero knowledge proof, and why Ethereum utilizes its as part of the scaling framework, let’s move to Solana, and how zk is currently being implemented.
Solana is a monolithic L1, with strong hardware requirements to run a full node. As the chain is optimized for security and speed, Solana allows for data to be decoupled from execution, and thus allows for parallel processing. It’s the implementation of parallel processing that has allowed Solana to scale with very cheap fees for mass adoption.
Utilizing zero-knowledge proof in the same way that zk-rollups are moving towards is not ideal for Solana, due to the extra computational requirements added to the monolithic chain. Solana’s design, first and foremost, is to squeeze out the power of hardware to provide the performance required. Implementing ZKP for privacy, however, is an endeavor worth taking.
Let’s dive deeper into the protocols that are on their way to achieving privacy at the protocol layer, including Light Protocol, and Elusiv Privacy. We will also touch on token-2022 and the confidential transfer extension, as well as the base layer optimizations that are being done to enable privacy on Solana.
But first,
Why Solana is not private by default?
Solana state is unencrypted, and this is a choice by design for most public blockchains. Public blockchains allow for trustless transparency, in which validators can observe and verify transactions to reach consensus without needing a centralized authoritative force. Blockchain transparency, as such, is seen as a feature of the network.
Another reason for Solana’s lack of privacy is that the blockchain utilizes the account model. In Solana, everything is an account. If Bob sends David 1 USDC on-chain, Solana’s system program will find the relevant accounts within the transaction and updates its balances accordingly. Fundamentally, it’s a slot-based updating of the state that leads to information leakage on whose account state is changing at any given moment.
With that background in mind, the bottlenecks for privacy on Solana become 2-folds:
creating a private/ encrypted state without revealing which state transition/account balance is being updated
get validators to verify that these state transitions are legit in a trustless/ minimized manner, as well as being cost-effective.
Solutions to implement privacy on Solana, at the application layer:
For protocols on Solana, the solution is to provide arbitrary data encryption and utilize zero-knowledge proof to prove ownership/knowledge of the encrypted data. This ensures that the data stays private (through encryption) while still being verifiable by the network for inclusion.
Light Protocol and Elusiv Privacy both utilize this approach, while the implementation between the two differs slightly.
source: lightprotocol.com
source: Elusiv.co
Data Encryption
Both protocols utilize the UTXO model to create a private pool on-chain. The pool aggregates users’ deposit, without revealing which funds belongs to whom. Only users with knowledge of their deposit identifiers can instruct the pool to spend the respective remaining funds from the pool.
UTXO stands for Unspent Transaction Output. Instead of having an actual address balance updated in place when a transaction occurs, it’s a series of append-only to the current state. By utilizing this model, what actually being witnessed on-chain is the addition of a few encrypted bytes (a UTXO) to a growing list of encrypted UTXOs. New states added to the growing on-chain UTXO means that the past state is concealed, and observers cannot track it without having access to the UTXO.
This is different from the account model generally used in PoS networks, like Solana. Each state transition (transaction updates between accounts) results in a direct balance change, similar to your normal banking balance.
source: Horizen Academy
Each UTXO has a hash-based commitment, validating the UTXO, and a nullifier, signaling it has been spent. The nullifier is an identifier to the UTXO, and is generally used to signal ownership over unspent funds. In essence, the UTXO model allows the relationship between the sender and the recipient to be decoupled, making it harder for transaction info to be traced.
Hash-based commitments;
Since we are using the protocols as middlemen to initiate private transactions, it makes sense to architect in a way that user private balances themselves are not leaked to the protocol. This is where hash-based commitment comes in.
hash-based commitment schemes are powerful cryptographic tools that allow one to commit to a chosen value via hashing while keeping it hidden from others, with the possibility of revealing the value later on. Hash-based commitments have some amazing properties that make them the perfect tool for privacy applications
Binding: Once a commitment is made, the internal data cannot be changed. In a commitment scheme with multiple input values, there won’t exist a value combo that would create the same commitment.
Hiding: Hash-based commitments are one-way, which means the internal value of the commitment won’t be leaked by only knowing the commitment.
For both Light and Elusiv, by running users’ deposit data (token amount, and token type) through the hash, It is almost impossible for protocols to check the internal value inside the hash, unless being revealed, and for users to adjust the data info, and thus provide total privacy and prevent double-spending.
Verification:
The second part of the process is to verify the encrypted data without revealing identifiable information. For both protocols, this is where zero knowledge comes into play.
It is also important to understand how Commitments and Nullifiers are constructed in the context of Light and Elusiv, as the relationship between various data points will determine how ZKP is implemented.
Light Protocol:
In Light protocol. the commitment hash is derived as follows:
getCommitmentHash():
return commitment = poseidonHash(AmountsHash, Keypair.publicKey, Blinding, AssetsHash, InstructionType, PoolType, VerifierPubkey)
getNullifierHash():
return nullifierHash = poseidonHash(commitment, merkleTreeLeafIndex, signature);
What we see here is that the nullifier is derived deterministically from the commitment, and is only computed after the “commitment” value is returned. The commitment is stored as a leaf of the on-chain Merkle tree.
To provide anonymity, the protocol initiated a Merkle Proof, or a Set membership proof, in a zero-knowledge proof. Through verification, the protocol can show the hash of the UTXO is a leaf that belongs to a Merkle tree root, but without revealing which UTXO is being considered.
This is doable due to the unique property of hash functions called Binding that we discussed previously. Once the data is committed, it cannot be altered by the sender. Any change to the underlying data means changes to the hash of the leaves and changes to the root of the tree.
source: Geeksforgeeks
By proving the tree's root as public input, the protocol can ensure that the UTXO, validated by the hash, is accurate. No user address or signature is involved in the process, which essentially decoupled users’ involvement from the movement of funds.
Through Private Solana Programs (PSPs), the program logic is encoded into zero-knowledge circuits on the client side, generating a zk-SNARK proof sent on-chain for verification.
Elusiv Privacy:
When an user deposits funds into Elusiv, the protocols create a commitment of C stored on-chain and derived as
C = H(x| y| n)with
H, x, y, n stands for :
The hash-function H
the concatenation of the fund amount of x,
the asset type y,
nullifier n, which is a secret value kept hidden by the user depositing the funds.
By putting the values of x, and y through the hash, the protocol ensures that there is no leakage to the user's private balance on-chain.
To ensure users’ claim of knowing specific x & y to their commitment, Elusiv uses zero-knowledge proof to prove knowledge of the nullifier n, as seen in the commitment formula above.
Instead of revealing the value of |n|, it simply provides proof that embeds the knowledge of this secret value, without leaking information about the commitment. Users will not fear adversarial linkage to the associated commitment or intercepting.
Private Balance, Nullifiers, and Relays
Once deposits and masking of the deposits have been made the protocol also needs to design the system so that the funds can move out in a private manner. This is where Private Balance, Nullifiers, and Relays come into play.
For both Light Protocol and Elusiv Privacy, users are requested to create a Private Balance with the protocols, as such, authorize the protocols to spend the funds within this Private Balance. This allows for funds movement to the outside world being decoupled away from users’ public keys. It’s important to note that users are in control of these Private Balances, and both Light nor Elusiv do not have the authority or access over your balance and its movement.
Nullifiers, as explained above, act as an agent to confirm ownership over the Unspent Balance. And finally, the relayers come in, to fully complete the privacy loop for transfers. Relayers (Light Protocol) and Warden Network (Elusiv) both play a similar role in their respective protocols, in which they forward users’ instructions from the client to the blockchain, pay for the ZKP verification, and earn a successful fee.
Further Application Developments
The combination of the tools and configurations above allows for robust systems of private transactions to flourish on Solana, thanks to the hard and dedicated work of the teams at Light Protocol and Elusiv Privacy. And throughout the bear market, the teams haven’t stopped shipping.
Light Protocol
Light Protocol has released a new and improved V3 of their protocol. In V3, the arbitrary state transition is available via Private Solana Program, with great flexibility in bringing program logic to the client and utilizing syscalls to improve atomic verification.
Light’s go-to-market focus is on ZK applications. A highlight of this endeavor is the upcoming collaboration with 21|12 Foundation on ZKVerse, which is slated to launch in 2023. As the first collaboration of its kind, it is excited to see how Privacy tech will translate in the context of NFTs, and enrich users’ experience and developer design space moving forward.
The team behind the project has contributed and maintained Fade, the first-ever and only product suite for privacy minting and launchpad on Solana, as well as other ventures across the ecosystem.
Elusiv Privacy
Elusiv welcomed the month of June with the launch of their SDK, allowing developers to access privacy toolings on Solana, without having to reason through complex cryptography. The team has also expanded the protocol offerings, by beginning to onboarding and integrating with ecosystem assets and partners for private assets transfers, including $SAMO, $BONK, and $mSOL
Elusiv’s emphasis runs deep into payments, and it upcoming roadmap is nonetheless exciting. Elusiv also is building out its decentralized and permissionless compliance mechanism for web3 that could replace fully centralized/KYC processes. The system starts with a viewing key, allowing for the reveal of private transactions securely and atomically, and will be completed with a series of features to be a full product suite, which includes
the APA system (Autonomous Payment Analytics) for community-driven blocklist against malicious actors
Warden Network compliance system for on-chain flagging, and prevent them from using Elusiv, and as such, prevent negative association against your use of the protocol
Solana Protocol Privacy Development:
On the core development for the Solana Protocol, the most interesting privacy-related development has been the Token-2022 privacy extension.
Token-2022 is the new superset of functionalities provided by the Token Program, born from developers' need to add new actions and features to their token program. These functionalities are added via extensions, with new fields in mints and accounts, to support new layouts in Token-2022.
The current Token-2022 is still under audit and not-recommended for full production use. However, this hasn’t stopped the community from actively experimenting and integrating with the new standard, with $BERN and Fluxbeam dominating the highlight reel.
Solscan has also supported token-22 in our newest updates.
The difference between Solana’s confidential transfers and the protocols above is that token22 will only provide balance confidentiality, while Elusiv (and Light) will provide full account anonymity.
Under the hood, what’s interesting is how zero-knowledge will be implemented, along with enablements within the Solana protocol. From Token-2022 Project Status, here are some highlights that we find worth paying attention to:
V1.16 curve syscalls:
Instead of fully executing the computation for the proof verification process (addition and scalar multiplication on the elliptic curve operations, optimal pairing check for zk-SNARK verification within computing unit limit), these computations can be evoked via system calls (syscalls).
syscalls are precompiled computations included directly inside the Solana core and make your operations “much” more efficient. The result is efficient verification in 1 atomic transaction, which only costs less than 200 computing unit
Zk-token SDK, and proof split:
to fit within the current transaction size limit, the proof will have to be split into multiple parts and uploaded to the chain through multiple transactions. The zero-knowledge token SDK will be used to split the proof, and the token-2022 must properly consume the new proof format
Wallet support:
Wallets will need to support Token-22, by fetching token-22 accounts and sending instructions to the proper program.
Wallets will also create zero-knowledge proofs, which entails new transaction flows.
Conclusion:
Privacy is a fundamental right, and the end user should ve the final say in seeing how their transactional data is being displayed in the P2P world. With Zero-knowledge Proof implementations on Solana, it is much more efficient and composable for Developers to directly deployed on Solana. The future is bright, and the team at Solscan maintains our bullish stance on the tech, and the ecosystems at large. Truly excited for the future, with additional use cases and design spaces for better user experiences on Solana!