## Introduction

We want to create rollups that:

1. Use Celestia for DA,
2. Use Neutron for settlement (for this, every rollup has a contract on Neutron).

The problem is that these rollups need a way to verify that their data is indeed available on Celestia. To give them the ability to do this quickly and easily, we plan to ask our validators to run a Celestia light client right next to neutrond and send DA attestations through vote extensions.

That is, DA attestations are now attached to votes, and if 2/3 of the attestations for a particular height are collected, we consider the data for this height to be available and save the block header in the state of the module.

After that, through the query interface of this module, we can tell the rollups something along these lines: hi, we are confident that a particular block has exactly this header, and we can provide evidence that your block's data is indeed in this block.

## Question 1

Because I don't understand well how the settlement contract on Neutron might operate, I'm unclear about what specific proofs we should provide to this contract — apart from the fact that the blob with its block, which it once sent to the Celestia validators, is indeed accessible.

What does a rollup's fraud-proof represent, specifically? How is it tied to the fact of data availability on Celestia, especially considering that there's no direct access to the data itself, only access to an inclusion proof? Is there any examples that I can look at, or any articles that give more details on fraud proofs for optimistic rollups?

## Question #2

If I understand everything correctly, the rollups using Celestia for DA:

1. Will be optimistic, meaning their settlement contract, which resides on Neutron, will accept fraud proofs,
2. Will store the blocks themselves on Celestia.

The asynchronous nature of this whole setup unnerves me.

There's a rollup, leading its own life. At some point, it produces its block, turns it into a blob, and sends it to the Celestia validators.

After finalizing their block (which contains the blob-block of our rollup), the Celestia validators might take an indefinite amount of time to distribute it to the full-nodes.

There are light-clients, each communicating with its set of full-nodes. For every block on Celestia, they wait for some time until the full-nodes have enough data on that block to perform DA and verify everything.

Then, there's our application running light-nodes. Based on 2/3 votes, it decides at some point that a certain block on Celestia exists and is indeed valid.

And at the top of this mess is the rollup settling on Neutron.

**A.** How long will this rollup have to wait before the block it once submitted to Celestia is considered final? I mean, potentially for a very long time. Is this even okay? Moreover, it needs to wait not only to check that its data is on Celestia. It also needs to wait for its own fraud proofs.

**B.** As far as I understand, a Celestia full-node doesn't always retain complete data of every block. Isn't it possible for a situation where a light-client has already deemed a block valid (having received its header, done data sampling) and then communicates with another node and receives a fraud-proof for that block? I assume that the answer is "yes, but it's **very** unlikely". Still, what should the rollup do if a fraud-proof for a block previously considered valid suddenly arrives at the Celestia level? Does it have to roll back its entire state up to that height?

**C.** Our application, collecting DA attestations through validators, also seems to need a way to obtain fraud proofs for all blocks that we have already reported to Neutron as valid and mark them as invalid. Is that so?