-
Notifications
You must be signed in to change notification settings - Fork 390
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: add documentation on how to build rollups on Celestia
- Loading branch information
Showing
1 changed file
with
54 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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? |