Solana, the industry leader in building web3 experiences at scale, has introduced state compression, a new way to store data directly on-chain that cuts down on cost by magnitudes of scale. State compression is already being used by teams across the Solana ecosystem, including Dialect and Crossmint, to power large, user-friendly experiences.

Although state compression can be used to store any sort of data on-chain, the first use of this innovative technology is compressed NFTs, which drastically reduces the cost of minting NFTs. State compression is a novel technology primitive that takes advantage of Merkle trees, allowing developers to store a small bit of data on-chain and updates directly in the Solana ledger, cutting the data storage cost down dramatically while still using the security and decentralization of Solana's base layer.

Jon Wong is technical lead on the ecosystem engineering team at the Solana Foundation.

After numerous phases of development, adoption, and rollout, compressed NFTs are live on Solana’s mainnet-beta and powering the next wave of novel on-chain product experiences. Compressed NFTs are 2,400-24,000x cheaper than their uncompressed counterparts, while still retaining identical structures. Now minting 100 million NFTs on Solana costs only ◎50!

For the developers who want to get started with compressed NFTs, there are five key things to know:

Understand Merkle trees

State compression takes advantage of Merkle trees, a data structure known for its capability to “compress” the verifiability of a tree of data into a “hash,” or “fingerprint,” of the current state of the tree. The Merkle roots are stored on-chain and updates are stored directly in the Solana ledger, meaning anyone can verifiably (and permissionlessly) reconstruct the tree, combining a vast amount of verifiable off-chain storage with a low overall cost of on-chain storage.

Engineers at Solana Labs added the capability to concurrently update Merkle trees multiple times in the same block by allowing the fast-forwarding of stale proofs. This capability is unique to Solana. See more in the whitepaper.

Initialize the tree

The first thing you need to do is initialize the Merkle tree. There are three parameters to any Merkle tree: 1) Depth (capacity), 2) buffer size (concurrency / latency), and 3) canopy height (composability).

Depth is easy — the capacity of a perfectly balanced concurrent Merkle tree is 2^{DEPTH}, and trees can be configured to hold anywhere from eight leaves all the way up to a billion (2^30). In this case, leaves can be NFTs.

Buffer size is an approximation of the number of concurrent updates that can happen in the same block. Merkle trees typically have an issue whereby any modification of the tree causes any previously computed proofs to go out-of-date, but with this novel concurrent Merkle tree implementation, stale proofs can be fast-forwarded and still be accepted by the smart contract. A buffer size of 64 means that any given proof will still remain valid for up to 64 updates of the tree, after which it must be recomputed. Buffer size can be anywhere from eight to 2048.

Canopy height specifies the portion of the tree that remains on-chain, reducing the amount of proofs that have to be submitted by clients for verification. Given the current transaction size limits on Solana, this is the only feasible way to pass enough proofs to be able to validate the existence of trees with a depth > 20. Canopy height maxes out at 17.

Rather than initialize one giant tree to hold everything, I recommend issuing numerous, smaller trees of varying sizes. This reduces write-lock contention on the tree account, as well as provides more opportunities for composability by reducing the number of proofs needed to be submitted for any given modification.

Choose a canopy height that maximizes composability — while it costs more in rent, a canopy height that is DEPTH-3 provides a similar interface to existing NFT-related smart contracts that already pass 3 accounts. For example, a tree of depth 20 could have a canopy of 17 so that clients only need to submit three proofs to make any modification to a tree.

Mint an NFT

Tooling for minting compressed NFTs is already live. Bubblegum, the smart contract written by Metaplex that powers compressed NFTs, uses state compression under the hood. Mint, transfer, and replace instructions should be issued against the Bubblegum smart contract. Mints do not require proofs, so anyone can mint compressed NFTs as easily as before.

Use an RPC to get the latest data

Compressed NFTs eschew the typical on-chain account approach, and because data related to trees is being issued into the Solana ledger, RPCs are required to make the “read” experience nice and snappy. Helius, SimpleHash, and Triton all have support for compressed NFTs, and 2/3 implement the Metaplex Read API—a uniform interface for retrieving all the information necessary about both compressed and uncompressed NFTs.

Use proofs to transfer NFTs

Because of how compressed NFTs are stored, any modifications to those NFTs (such as an ownership change, or an update to the metadata like the collection information) requires a modification of the storage tree itself. In order to do so, one must compute the proofs needed to signify that you know the latest state of the tree, along with the signature of the leaf owner (or delegate).

Merkle tree proofs are the set of hashes that can be used to prove that the leaf was in the tree to begin with. RPC nodes can provide this with the `getAssetProof` Read API RPC method. Depending on the canopy height of the tree, one can submit a subset of the proof path and let the on-chain program handle reconciling the rest of it.

Submit the proofs along with the modification you want to make (a new owner!) and send the transaction. Voila!

Once you’ve understood these concepts, you should be ready to take advantage of compressed NFTs and build brand new experiences.

Here are some additional resources for you to explore: