to query the program examples in natural language.High Level System Overview
This is how it works at a high level:Storage of Compressed State
Compressed accounts store state as call data in Solana’s ledger[^1], removing rent per account.Accessing Compressed State
Transactions specify state they access (read/write) and include it in the transaction payload.State Validation
Solana Programs the to update compressed state- The protocol validates the state (validity of existing state, sum checks, ownership checks)
- The protocol enforces a schema: Classic Accounts → Compressed Accounts.
Compressed accounts have a layout similar to classic accounts.
State Updates
The new state is recorded as a log on the Solana ledger with each transaction.Photon RPC Nodes
index the state changes, making the compressed account state available to clients via the ZK Compression RPC API.Forester Nodes
Keeper nodes that interact with the to empty queues and rollover state trees.Clients and custom programs do not interact with Forester nodes or the Account Compression Program. This is all done under the hood.
Next Steps
In the following sections, we’ll dive into the core concepts that make ZK Compression possible:- Compressed Account Model: Understand how compressed accounts differ from regular Solana accounts (not much!) and how they enhance efficiency.
- State Trees: Learn about the Merkle tree structure used to store compressed accounts and how it minimizes on-chain storage.
- Validity Proofs: Explore how the protocol uses zero-knowledge proofs to verify data validity while keeping proof sizes small.
- Lifecycle of a Transaction: Follow the journey of a ZK-compressed transaction from creation to execution.
- Considerations: Discover the trade-offs and scenarios where ZK Compression may or may not be the best solution.