You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $40/month you can upgrade to our FULL library of 60+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 

Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

• Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
• Early access to future CORE ratings: Being early is sometimes just as important as being right!
• Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
• CORE report Audio playback: Don’t want to read? No problem! Listen on the go.

Introduction

Solana, renowned for its high-performance blockchain capabilities, has introduced compressed non-fungible tokens (NFTs) to revolutionize the minting and management processes. This advancement enables the creation of millions of NFTs at a fraction of the previous cost. This article delves into the mechanisms behind Solana's compressed NFTs, explores its dual storage spaces, and examines the application of zero-knowledge (ZK) proofs in optimizing this technology.

Understanding ZK Compression

Zero-knowledge (ZK) compression on Solana represents a significant departure from traditional data compression methods. Rather than using conventional algorithms, ZK compression employs state compression to store account data in Solana's more cost-effective ledger space. This approach maintains the security, performance, and composability of the Solana Layer 1 (L1) while dramatically reducing costs. For instance, creating a 100-byte PDA account costs approximately 0.0016 SOL without compression, but only 0.00001 SOL with compression, a reduction factor of 160x. Similarly, creating 100 token accounts costs around 0.2 SOL regularly, but just 0.00004 SOL with compression, achieving a reduction factor of 5000x.

The Mechanics of ZK Compression

ZK compression on Solana utilizes zero-knowledge proofs (ZKPs) to efficiently manage the Merkle tree membership logic. A specialized circuit processes account data along with a 128-byte proof to verify the inclusion of data in the on-chain "commitment." This proof leverages elliptic curve cryptography, ensuring that its size remains a manageable 128 bytes, optimizing space for small account data. Traditional Merkle proofs grow logarithmically with the number of accounts, such as 550 bytes for 100,000 accounts, whereas ZK compression maintains a constant proof size, facilitating scalability.

Functionality of ZK Compression

The core principle of ZK compression lies in its ability to verify account states without necessitating on-chain storage of all data. Here is a breakdown of the process:

• Data and Proofs: Instead of storing complete account data on-chain, each transaction provides the data along with a concise proof (128 bytes). This proof confirms that the data is part of the on-chain commitment.
• Constant Proof Size: Unlike Merkle proofs, which expand with the number of accounts, ZK compression keeps the proof size constant, allowing for the efficient management of numerous accounts under a single commitment.

On-Chain Verification and Off-Chain Proof Generation

Proof generation for ZK compression is performed off-chain to conserve computational resources. However, the verification process must occur on-chain to ensure the accuracy of the provided account data before permitting further execution. The specific prover system employed by ZK compression is called Groth16, which utilizes the alt_bn128 syscall. Currently, this feature is under testing and feature-gated on Solana's mainnet, enabling the verification of arbitrary computations, not limited to Merkle tree membership.

Developer Abstraction and Benefits

One of the significant advantages of ZK compression is the abstraction of complex ZK aspects, allowing developers to interact with compressed accounts similarly to regular accounts without needing an in-depth understanding of ZK technology. This abstraction simplifies development and encourages broader adoption by lowering the technical barrier to entry.

Components of ZK Compression

Concurrent Merkle Trees

A Merkle tree is a binary tree data structure where each non-leaf node (branch) is a cryptographic hash of its child nodes, and the leaf nodes contain the actual data. The root hash, computed from all leaf nodes, uniquely represents the entire dataset. In a concurrent Merkle tree, whenever data in a leaf node changes, the root hash is recalculated, ensuring data integrity.

Traditional Merkle trees face challenges with concurrent writes because any change invalidates the previous root hash. This issue is resolved in ZK compression by allowing concurrent operations and ensuring that the latest state is always accurately represented. In Solana, NFT metadata is stored in the leaf nodes of concurrent Merkle trees within the ledger space. The root hash of these trees is then posted to the state space. For instance, if an NFT is transferred from Joel to Saurabh, the application retrieves proof of the NFT's current ownership from the ledger space and verifies it against the latest on-chain hash in the state space. Upon verification, the transaction is processed, and both the tree in the ledger space and its root hash in the state space are updated accordingly.

Zero-Knowledge Proofs

Zero-knowledge proofs (ZKPs) allow one party (the prover) to prove the validity of a statement to another party (the verifier) without revealing any additional information. This concept can be illustrated through simple analogies:

• Where's Waldo: Alice finds Waldo in a picture and wants to prove it to Bob without revealing Waldo's location. She uses a large cardboard with a hole that shows only Waldo when placed over the picture. Bob sees Waldo but learns nothing about his coordinates, proving Alice's claim without additional information.
• Two Balls: Bob, who can distinguish colors, demonstrates this to Alice, who is colorblind, by having her hold two balls of different colors. She hides them behind her back, optionally swaps them, and shows them to Bob, who identifies if they were swapped. Repeating this process enough times statistically convinces Alice of Bob's ability without revealing the colors themselves.

ZKPs allow for the verification of computations without re-running them. For example, after computing a result and generating a proof, others can verify the correctness of the computation by checking the proof, regardless of the computation's complexity. This feature is applicable to any arbitrary computation, from simple arithmetic to validating multiple digital signatures. The primary advantage of ZKPs is their ability to turn complex computational problems into a single proof verification task, significantly reducing the computational burden on verifiers. However, generating these proofs can be time-consuming.

Extending Utility with Zero-Knowledge Proofs

The introduction of ZK proofs extends the utility of the compressed NFT framework to support any state changes. The concurrent Merkle tree, termed the state tree in this context, now stores programs (smart contracts) instead of NFT metadata. The state tree's root hash is maintained in the state space.

When an application intends to modify a compressed state, it gathers and submits a ZK proof validating the state transition against the on-chain hash. Once validated, the protocol updates the state tree and posts the changes to the ledger. This enhanced flexibility, facilitated by zero-knowledge proofs, allows developers to post and verify proofs of arbitrary computations. Consequently, the compression technology's use case extends beyond NFTs to encompass a broader range of Solana programs, including new token contracts.

Process of Balance Update

When a user's token balance requires updating, such as when transferring tokens to another account, a ZK proof is generated. This proof ensures that the user's current balance aligns with the on-chain root hash. Once the proof is verified, the Solana network executes the necessary computations to update the token balance and the Merkle tree structure accordingly.

Role of Off-Chain Infrastructure

Since the majority of data is stored in Solana's ledger space, which nodes are not required to retain in full, additional off-chain infrastructure providers play a crucial role. Indexers or Remote Procedure Call (RPC) nodes, such as Helius, assist in generating ZK proofs and supply the off-chain data needed for the workflow. This collaboration between on-chain and off-chain resources enables efficient and secure updates to user balances.