## Proposal Overview

We propose to integrate Celestia's robust data availability framework with Mina's zk-based applications. This fusion aims to enhance the reliability of Mina's zk-apps, ensuring data availability. By combining Mina's compact design with Celestia's data layer, we strive for resilient and efficient decentralized applications.

### Problem Statement

zk-SNARK-based applications on Mina currently lack a dedicated mechanism for guaranteed data availability. This gap poses risks of data inconsistencies and vulnerabilities to malicious actors, undermining the platform's reliability.

While Mina ensures a lightweight and scalable design, it inherently poses a data availability challenge. Unlike traditional blockchains where full nodes maintain a comprehensive transaction history, Mina's nodes retain only the latest state. This design, while efficient, necessitates reliance on off-chain data for historical transactions. Consequently, while Mina optimizes for size and scalability, it introduces potential vulnerabilities related to the availability and verification of past transactional data, as there's an implicit trust in external storage systems to maintain and provide that data when needed.

### Solution

The primary aim of the Celestia-Mina Bridge is to harness Celestia's robust data availability properties and Mina's zk-SNARKs-based efficient execution mechanism. This integration aims to provide a seamless, scalable, and secure platform for users, ensuring transactions are not only executed with integrity but also are always available and resistant to censorship.

Celestia is tailored to be a blockchain that excels in data availability by decoupling consensus from execution. Traditional blockchains merge the processes of consensus and transaction execution, but Celestia's focus solely on consensus allows it to efficiently ensure that data, in the form of blocks, is widely available without the overhead of transaction processing. This emphasis is further enhanced by the platform's utilization of cryptographic data availability proofs, ensuring data is both retrievable and resistant to censorship. Leveraging erasure coding techniques, Celestia also optimizes block propagation, allowing for the reconstruction of entire blocks even if only parts of it reach segments of the network. This design not only facilitates high throughput but also ensures interoperability, making Celestia a versatile "plug-and-play" data availability layer for a myriad of decentralized systems. Furthermore, its architecture allows light clients to effortlessly verify data availability proofs without downloading the entire dataset, which is advantageous for resource-constrained devices.

The Mina-Celestia bridge uses Celestia's strong data storage features to support Mina's small zk-SNARKs design. With Celestia, Mina can always check transactions and changes, solving any data storage worries. Celestia handles consensus, so Mina can process transactions quickly. The bridge makes both systems work better together, combining Mina's speed with Celestia's storage.

## Architecture & Design


### Design
1. **User Transaction with ZK Proofs:**
- **Transaction Initiation:** User generates a transaction execution proof.
- **Broadcasting to Celestia:** This proof & associated public parameters broadcasted to the Celestia network, targeting specific data namespaces assocated with the ZK application.

2. **Data Availability in Celestia Block:**
- **Commitment Creation:** A cryptographic commitment is generated as the block gets finalized in Celestia, serving as an efficient and tamper-proof representation of the posted data.

3. **Sequencing of Data:**
- **Data Retrieval from Celestia:** Relevant data (block header, commitment, ZK proof) is extracted from Celestia, leveraging its data availability sampling capabilities.
- **Sequencing Role**: The sequencer extracts this commitment and arranges it in accordance to Celestia, ensuring it adheres to any temporal or logical requirements necessary for off-chain validation.

4. **Off-Chain Prover Validation:**
- **Reconstruction from Sequenced Data**: Using the sequenced data, the off-chain prover (in Plonky2) attempts to reconstruct the commitment to ensure the integrity of the data from Celestia.
- **Proof Generation**: Upon successful reconstruction, a ZK proof is generated, confirming the authenticity of the transaction execution and the corresponding data posted in the Celestia block.

5. **ZK App Verification on Mina:**
- **Proof Handling**: The ZK App, rooted in Mina, receives the aggregated proof (proof of execution and data availability).
- **State Transition**: Upon successful verification, the ZK App's internal state is updated to reflect the changes of the transaction, ensuring the execution's validity and the data's availability.

### Project Goals:
1. Design and develop a proving system (Plonky2) for the Celestia namespace tree inclusion to be verified in SnarkyJS.
2. Design and develop a proving system (Plonky2) for tendermint consensus and verified in SnarkyJS.
3. Design an API for ZK applications to easily integrate and use Celestia's data availability capabilities.

### Existing Work
LambdaClass ZK hackathon POC implementation:

This works with a sidechain/multisig that acts as an authenticator for blob inclusion

1. Users transmit data to Celestia
2. Users request a signature from Signers that confirm the data is accessible and has been disseminated to the network
3. The Signer committee verifies whether the data is accessible and has been distributed across the network. They then sign a message using the Poseidon hash algorithm.
4. The Signer committee provides signatures to users
5. Users send the transaction with signatures.

### Vision and Project Longevity

This section provides details about the long-term vision for your project. Electors will be referencing this section when thinking about your proposed project’s ‘Impact’ and ‘Scalability & Growth Potential’
### What is your long-term vision for this project if your proposal is funded? What is your dream scenario for how this project could evolve?

The vision of the Mina-Celestia bridge project is to create a seamless integration between Mina's lightweight zk-SNARKs design and Celestia's data storage strengths. By doing so, the project aims to ensure rapid and secure transaction processing in Mina, while also addressing any data availability concerns with the robust storage capabilities of Celestia. Ultimately, the goal is to provide a reliable and efficient platform for users and developers, fostering trust and expanding the potential applications of both blockchains.

### Do you have a business model or monetization plan in mind?
This will be detailed later
## Budget and Milestones

This section provides details about the proposal's funding needs. How much funding is required? How will those funds be spent? What will be accomplished? Reference the Cohort 1 Funded Proposals for examples on how this section can be filled out.

Please keep in mind that ‘Feasibility’ is one of the criteria that electors will be considering when reviewing this section.
### Standard Budget

??
### Standard Scope
This will be detailed later
### Standard Scope Milestones
This will be detailed later
Advanced Budget

??
### Advanced Scope
This will be detailed later
### Advanced Scope Milestones
This will be detailed later
## Risks and Unknowns

This section provides details about the proposal's risks and unknowns. What challenges may be faced, and how might they be dealt with? Electors will be referencing this section when considering the ‘Feasibility’ criteria.
### Risks
This will be detailed later
### Proposer Name

Yunus Gürlek
### Proposer Github
https://github.com/yunus433
### Proposer Experience
This will be detailed later
## Team Info

This section provides details about the proposal team.
### Team Members
This will be detailed later
### Other Proposals

This will be detailed later
(Optional) Please attach a 2-3 slide ‘pitch’ deck that summarizes your proposal.

This deck will be referenced by electors and community members when viewing your proposal.
### Cohort 1 Participation

Please note that if you were funded as part of Cohort 1, your proposed milestones for Cohort 2 must be a progression from the proposed milestones for Cohort 1. See ‘Builder FAQ’ for more details.
Cohort 1 Participation