Skip to content

Commit

Permalink
docs: add documentation on how to build rollups on Celestia
Browse files Browse the repository at this point in the history
  • Loading branch information
rach-id committed Mar 20, 2024
1 parent 5928279 commit 1c5a92a
Showing 1 changed file with 54 additions and 0 deletions.
54 changes: 54 additions & 0 deletions developers/blobstream-rollups.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
---
description: Learn how to build rollups that use Blobstream
---

## Optimistic rollups

The easiest to build with Blobstream are optimistic rollups. An optimistic rollup is a rollup that commits optimistically to a set of blocks, and allows the other parties to verify that the blocks are valid, and if they're not, they can create fraud proofs to signal that.

Through the use of Blobstream, Celestia allows optimistic rollups to use Celestia as a DA layer, i.e. posting all the rollup data to Celestia, and only send commitments to the settlement contract. Then, users can use Blobstream as a source of truth to verify the rollup data and create fraud proofs in case of a misbehavior.

To build an optimistic rollup that uses Celestia as a DA layer, the following constructions can be inspired by.

### Optimistic rollups that uses a sequence of spans

One way to construct an optimistic rollup that uses Celestia as a DA layer is to post the rollup data in Celestia. Then in the rollup header, use the following information to reference a sequence of spans, aka a data pointer:

- Height: the height of the Celestia block containing the rollup data
- Start share: which is the index of the first share containing the rollup data
- Data length: which is the number of shares that the rollup data occupies

Note: If the rollup data is submitted in multiple blocks, the above sequence of spans can be generalized to include multiple blocks. For simplicity, we will stick with the data only submitted to a single Celestia block.

Now that this information is saved in the rollup header/settlement contract, users/rollup full nodes will be able to query for the rollup data from Celestia and verify that it's valid. And if it's not, fraud proofs can be generated.

The fraud proofs in this setup are discussed in the [inclusion proofs](https://github.com/celestiaorg/blobstream-contracts/blob/master/docs/inclusion-proofs.md) documentation.

### Optimistic rollups that use the data commitment

Another way to build a rollup is to replace the sequence of spans with a height and a share commitment. Then, users/rollup full nodes will be able to query that data, and in case of a dispute, they can create a fraud proof.

The difference between the above construction and this one is that the proofs used will be different: when using a sequence of spans, the inclusion proofs will be straight from the rollup data up to the [data root tuple root](https://github.com/celestiaorg/blobstream-contracts/blob/master/README.md#how-it-works). However, in the case of the use of the height and the share commitment, an extra step would need to be done when posting the header to the settlement contract, which is proving that the provided commitment is part of the Celestia block (referenced by its height). Then, fraud proofs will need to prove the following:

- share inclusion to the share commitment
- share commitment inclusion to the data root tuple root

Once these are valid, the rollup contract can proceed to parse the share and verify the contested claim.

Note: **Generating/verifying share commitment proofs is still not supported. Thus, the [sequence of spans](#optimistic-rollups-that-uses-a-sequence-of-spans) approach is preferable at the moment.**

## Zk-Rollups

Zk-rollups, aka validity rollups, can also use Celestia as a DA and Blobstream to verify that the data was posted. However, the submission process is different from the above constructions, since there are no fraud proofs, and everything should be verified when submitting the headers.

So, when posting to the settlement contract, the rollup data in Celestia can be referenced either using a share commitment or a sequence of spans, and a height. However, as explained above, the share commitment proofs generation/verification is still not supported. Thus, we will focus on the case where we use a sequence of spans. Check the [Optimistic rollups that uses a sequence of spans](#optimistic-rollups-that-uses-a-sequence-of-spans) for more information.

So, when submitting the headers to the rollup settlement contract, the settlement contract will need to verify the following:

- Zk-proof of the state transitions, as traditional zk-rollups do
- Zk-proof of the rollup data to the data root tuple root
- Verify that the sequence of spans is valid, i.e., is part of the Celestia block referenced by its height.

Once these are valid, the settlement contract can be sure that the state transitions are valid, and the data was posted to Celestia.

Asking inputs from reviewers: when verifying that the sequence of spans exists, and the rollup data to the data root tuple root, how would we know that we're talking about the same data? I could create a zk-proof of a bunch of data to the data root tuple root, then provide an invalid sequence of spans, how would this be detected?

0 comments on commit 1c5a92a

Please sign in to comment.