ZK Compression
  • Introduction
    • Overview
    • Intro to Development
  • Event
    • 🗓️Event: 1000x Hackathon
  • Release Notes
    • JS - v0.21.0
  • Learn
    • In a Nutshell
    • Core Concepts
      • Compressed Account Model
      • State Trees
      • Validity Proofs
      • Lifecycle of a Transaction
      • Limitations
  • Developers
    • TypeScript Client
    • JSON RPC Methods
      • getCompressedAccount
      • getCompressedBalance
      • getCompressedTokenAccountBalance
      • getCompressedBalanceByOwner
      • getCompressedMintTokenHolders
      • getCompressedTokenBalancesByOwnerV2
      • getCompressedAccountsByOwner
      • getMultipleCompressedAccounts
      • getCompressedTokenAccountsByOwner
      • getCompressedTokenAccountsByDelegate
      • getTransactionWithCompressionInfo
      • getCompressedAccountProof
      • getMultipleCompressedAccountProofs
      • getMultipleNewAddressProofs
      • getValidityProof
      • getCompressionSignaturesForAccount
      • getCompressionSignaturesForAddress
      • getCompressionSignaturesForOwner
      • getCompressionSignaturesForTokenOwner
      • getLatestCompressionSignatures
      • getLatestNonVotingSignatures
      • getIndexerSlot
      • getIndexerHealth
    • Addresses and URLs
    • Creating Airdrops with Compressed Tokens
    • Using Token-2022
    • Add Compressed Token Support to Your Wallet
    • Create programs with the program-template
  • Node Operators
    • Run a Node
  • resources
    • Security
    • Privacy Policy
Powered by GitBook
On this page
  • General Recommendation
  • Larger Transaction Size
  • High Compute Unit Usage
  • State Cost Per Transaction
  • Next Steps

Was this helpful?

  1. Learn
  2. Core Concepts

Limitations

PreviousLifecycle of a TransactionNextTypeScript Client

Last updated 8 months ago

Was this helpful?

Before using ZK Compression to scale your application state, consider the following limitations of compressed accounts:

General Recommendation

Consider which accounts in your application benefit from ZK Compression and which don't. You can use both types for different parts of your application!

It may be preferred for an account not to be permanently compressed if:

  • The account gets updated very frequently within a single block (e.g., shared liquidity pools in a DeFi protocol).

  • You expect the lifetime number of writes to the same account to be very large (>>1000x).

  • The account stores large amounts of data, and you need to access a large part of it (>1kb) inside one on-chain transaction.

Larger Transaction Size

Solana's transaction size limit is 1232 Bytes. Transactions exceeding this limit will fail. ZK Compression increases your transaction size in two ways:

  • 128 bytes must be reserved for the validity proof, which is a constant size per transaction, assuming the transaction reads from at least one compressed account.

  • You must send the account data you want to read/write on-chain.

High Compute Unit Usage

System CU usage:

  • ~100,000 CU for validity proof verification, which is a constant size per transaction, assuming the transaction reads from at least one compressed account

  • ~6,000 CU per compressed account read/write

Example: a typical compressed token transfer uses around 292,000 CU.

Higher CU usage can:

  • Lead to usage limits: The total CU limit per transaction is 1,400,000 CU, and the per-block write lock limit per State tree is 12,000,000 CU.

State Cost Per Transaction

Each write operation incurs a small additional network cost. If you expect a single compressed account to amass a large amount of state updates, the lifetime cost of the compressed account may be higher than its uncompressed equivalent, which currently has a fixed per-byte rent cost at creation.

Type
Lamports
Notes

Solana base fee

5000 per signature

Compensates validators for processing transactions

Write new compressed account state

~300 per leaf (default)

Nullify old compressed account state

5000 per transaction

Create addresses

5000 per transaction

Same as nullify

Next Steps

~100,000 CU system use (state tree hashing et al.)

Require your users to increase their during congestion: Whenever Solana's global per-block CU limit (48,000,000 CU) is reached, validator clients may prioritize transactions with higher per-CU priority fees.

Whenever a writes to a compressed account, it nullifies the previous compressed account state and appends the new compressed account as a leaf to the state tree. Both of these actions incur costs that add to Solana's base fee.

Depends on tree depth: ~300 for the default depth of 26

Reimburses the cost of running a Forester transaction. The current default Forester node implementation can be found

Now you're familiar with the core concepts of ZK Compression, you're ready to take the next step! Dive into or with ZK Compression, or learn how to . For those interested in learning more about the fundamentals of ZK and its applications on Solana, we recommend reading the following:

(2tree_depth×tree_account_rent_cost×rollover_threshold)\left( 2^{\text{tree\_depth}} \times \text{tree\_account\_rent\_cost} \times \text{rollover\_threshold} \right) (2tree_depth×tree_account_rent_cost×rollover_threshold)
Poseidon
priority fee
transaction
building a program
application
set up and run your own node
Zero-Knowledge Proofs: An Introduction to the Fundamentals
Zero-Knowledge Proofs: Its Applications on Solana
Larger Transaction Size
High Compute Unit Usage
Per-Transaction State Cost
here