Kalypso is designed to operate with multiple data availability modes and currently supports calldata mode. This post discusses the various data availability (DA) options that could be integrated with Kalypso, highlighting their strengths and challenges.
Some Data Availability Modes
An insight into few possible data availability options and integrations for Kalypso
Calldata Mode (exists)
Proving data is sent to Kalypso over function calldata.
- Best For: Small input sizes
- Examples: Simple token transfers, basic smart contract interactions, signatures
- Limitations: Unsuitable for large data due to calldata size constraints
Ethereum DA
Proving data is posted on Ethereum DA, and its blob versioned hash, commitment and kzg proof are sent to Kalypso.
- Description: Default choice for many applications, utilizing Ethereum’s blockchain.
- Block Time: ~12 seconds
- Finality: ~12 minutes
- Use Case: Rollups who already post their L2 batches on Ethereum DA can simply provide blob hash* to kalypso to start proving.
Gnosis DA
Proving data is posted on Gnosis DA, and its blob versioned hash, commitment and kzg proof are sent to Kalypso.
- Description: Similar to Ethereum DA but with faster block times.
- Block Time: ~5 seconds
- Finality: ~5 minutes
- Use Case: Ideal for quicker proof validation at potentially lower costs.
Celestia DA
Proving data is posted on Celestia, and its namespace ID, commitment and Merkle Proofs are sent to Kalypso.
- Description: Operates with Merkle proofs instead of KZG proofs.
- Block Time: ~15 seconds
- Finality: ~15 seconds
- Use Case: Suitable for applications needing faster proof availability.
Eigen DA
Eigen DA has no concept of block time, which make it good fit for Kalypso. However, finality time is a tokenomic concern from prover’s point of view.
- Description: A newer model with no traditional block structure.
- Block Time: N/A
- Finality: ~12 minutes
- Use Case: Applications prioritizing very low proving times.
IPFS
- Description: Cost-effective, but with potential challenges in data availability.
- Block Time: N/A
- Finality: Not guaranteed unless pinned
- Use Case: Best for minimizing costs, with trade-offs in finality and reliability.
Comparison Table
| DA Mode | Finality Time | Cost | Best For | Challenges |
|---|---|---|---|---|
| Calldata | Instant | Low | Small input sizes | Limited by calldata size |
| Ethereum | ~12 minutes | High | Existing Rollups on Ethereum | Long finality time + High Cost |
| Gnosis | ~5 minutes | Low | Application that need ETH like DA but at cheap price | Long finality time |
| Celestia | ~15 seconds | Low | Fast proof availability | Adoption + Tooling |
| Eigen | ~12 minutes | Low | Long-term data availability | Adoption + Tooling + Long finality time |
| IPFS | Not guaranteed unless pinned | Very Low | Minimizing costs | Requires trusted pinning for guaranteed availability + Uncertain Availability Times |
Key Considerations
- Finality: Ensuring DA layers reach finality before Kalypso starts processes proofs, is crucial to avoid potential economic losses.
- Cost: Gnosis DA offers a balance between speed and cost, while IPFS provides a nearly free option with additional precautions.
- Speed: Celestia’s finality makes it a strong choice for time-sensitive applications.
By understanding the strengths and limitations of each DA mode, we can engage in a meaningful discussion in comment about which one should be integrated next with Kalypso to best serve our needs.