Infrastructure Options
Choose how to deploy the ZKSDK Privacy Coprocessor based on your security, performance, and sovereignty requirements.
Deployment Options
ZKSDK Network
Use our managed privacy coprocessor network. No infrastructure to maintain.
| Option | Description | Best For |
|---|---|---|
| Shared Workers | Cost-effective, multi-tenant privacy workers | Startups, testing, low-volume apps |
| Dedicated Workers | Single-tenant nodes reserved for your application | Production apps, predictable latency |
Consensus & Trustlessness Roadmap:
- Phase 1 (Current): Centralized attestation with TEE support
- Phase 2: Multi-node consensus with threshold signatures
- Phase 3: Fully decentralized network with economic security
Dedicated cloud nodes can optionally bypass consensus for maximum performance when trust assumptions allow.
On-Premise
Deploy privacy workers in your own datacenter or private cloud. Full data sovereignty.
| Consensus Mode | Description |
|---|---|
| ZKSDK Network Secured | Your workers, secured by our decentralized consensus |
| Private Consensus | Run your own consensus among internal nodes |
| No Consensus | Single-node deployment, bypass consensus entirely |
Enterprise features:
- Air-gapped deployment support
- Custom SLAs and support
- Hardware security module (HSM) integration
- Compliance-ready configurations
Data Storage
Where encrypted data is stored off-chain.
V0.1 Alpha (Current)
In the current alpha release, encrypted data is stored on the coprocessor worker's local database. This data is wiped regularly during development. Do not use for production data.
Future Versions
Users will be able to choose their preferred storage backend:
| Storage Option | Description | Best For |
|---|---|---|
| Postgres | Traditional database, self-hosted or managed | Enterprise, compliance requirements |
| IPFS | Decentralized content-addressed storage | Censorship resistance, permanence |
| DA Layer | Data availability layer (Celestia, EigenDA, etc.) | Maximum decentralization, rollup compatibility |
Architecture Overview
The ZKSDK Privacy Coprocessor enables private computation on any blockchain without revealing user data.
How It Works
1. Client Layer
- Users generate FHE keys locally using the SDK
- Secret key stays on the client - only the user can decrypt
- Public key and eval key are shared (safe - cannot decrypt)
2. Blockchain Layer
- Smart contracts store only encrypted data (ciphertext) and CID pointers
- No plaintext ever touches the chain
- Works with Solana, StarkNet, EVM, and more
3. Coprocessor Layer
- Privacy workers receive encrypted requests
- FHE Engine: Computes on ciphertext using eval keys only
- ZKP Engine: Generates validity proofs without seeing inputs
- Multiple nodes provide consensus and attestation
Key Security Model
| Component | Has Secret Key | Has Eval Key | Can Decrypt |
|---|---|---|---|
| Client | Yes | Yes | Yes |
| Coprocessor | No | Yes | No |
| Blockchain | No | No | No |
Privacy guarantee: Mathematical, not trust-based.
The coprocessor cannot decrypt your data - it only has evaluation keys that allow computation on ciphertext. This is enforced by cryptography, not policy.
Compare Options
| Feature | ZKSDK Network (Shared) | ZKSDK Network (Dedicated) | On-Premise |
|---|---|---|---|
| Setup time | Instant | 1-2 days | 1-2 weeks |
| Infrastructure | Managed | Managed | Self-managed |
| Consensus | Network | Optional | Configurable |
| Data location | ZKSDK Cloud | ZKSDK Cloud | Your datacenter |
| Cost model | Per-request | Monthly reserved | License |
| Support | Community | Priority | Enterprise SLA |
Get Started
ZKSDK Network: Start building immediately with our SDK documentation.
On-Premise / Enterprise: Contact team@zksdk.com for deployment options.