Crate spl_account_compression
source · [−]Expand description
SPL Account Compression is an on-chain program that exposes an interface to manipulating SPL ConcurrentMerkleTrees
A buffer of proof-like changelogs is stored on-chain that allow multiple proof-based writes to succeed within the same slot. This is accomplished by fast-forwarding out-of-date (or possibly invalid) proofs based on information stored in the changelogs. See a copy of the whitepaper here
To circumvent proof size restrictions stemming from Solana transaction size restrictions, SPL Account Compression also provides the ability to cache the upper most leaves of the concurrent merkle tree. This is called the “canopy”, and is stored at the end of the ConcurrentMerkleTreeAccount. More information can be found in the initialization instruction documentation.
While SPL ConcurrentMerkleTrees can generically store arbitrary information, one exemplified use-case is the Bubblegum contract, which uses SPL-Compression to store encoded information about NFTs. The use of SPL-Compression within Bubblegum allows for:
- up to 1 billion NFTs to be stored in a single account on-chain (>10,000x decrease in on-chain cost)
- up to 2048 concurrent updates per slot
Operationally, SPL ConcurrentMerkleTrees must be supplemented by off-chain indexers to cache information about leafs and to power an API that can supply up-to-date proofs to allow updates to the tree. All modifications to SPL ConcurrentMerkleTrees are settled on the Solana ledger via instructions against the SPL Compression contract. A production-ready indexer (Plerkle) can be found in the Metaplex program library
Modules
Accounts, where each field is
a Pubkey. This is useful for specifying accounts for a client.N levels of a SPL ConcurrentMerkleTree.#[program] mod is
associated with a struct defining the input arguments to the
method. These should be used directly, when one wants to serialize
Anchor instruction data, for example, when speciying
instructions on a client.Structs
authorityEnums
Statics
Functions
#[program] module in a way similar
to writing RPC request handlers. The macro then generates a bunch of
code wrapping these user defined methods into something that can be
executed on Solana.