Why Content-Addressable Storage?
FHE ciphertexts are large (10KB-100KB), but Solana account storage is expensive. Content-addressable storage solves this by:- Storing ciphertexts off-chain in a key-value store
- Using SHA256 hashes as keys (content addressing)
- Storing only 32-byte hashes on-chain
How It Works
Data Submission
When you submit encrypted data: The hash serves as both the key and a commitment to the data.Data Retrieval
When a program needs encrypted data:Program Interface
Loading Data
UseEncryptedRef::load() to fetch data from the store:
Storing Data
UseEncrypted::store() to submit results to the store:
Syscall Interface
Under the hood, the SDK uses two syscalls:fetch_data
submit_data
Data Lifecycle
Data Availability
The content store provides:| Property | Description |
|---|---|
| Persistence | Data remains available after transaction |
| Deduplication | Same data stored once (content-addressed) |
| Consistency | Hash commitment ensures data integrity |
| Availability | Sequencer ensures data is available for transactions |
Account Design Patterns
Minimal On-Chain Storage
Store only hash references in accounts:Multiple Encrypted Fields
Performance Considerations
Fetch Costs
| Factor | Impact |
|---|---|
| Ciphertext size | Larger = more memory/time |
| Number of fetches | Each fetch has overhead |
| Data locality | Sequential fetches may be batched |
Optimization Tips
- Batch operations: Load all needed values, then compute
- Minimize round-trips: Don’t load the same value multiple times
- Store at end: Submit results after all computation