-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[EPIC] Rollups fraud proofs using QGB #142
Comments
Hmmm. What's the need for decoding the PFB transaction itself? The point of posting the data root was so that the blobs can be used without looking at transactions. An alternative would be to revert to using (potentially in addition to the data root) tuple roots and have each tuple include addition metadata. |
Thats to prove that a transaction, which has a specific commitment, was posted to Celestia. We could use the blobs directly, but the proofs will be significantly bigger since we will need to send the whole rollup block to the solidity smart contract to be verified, as opposed to sending only the PFB. Also, using the blobs or the subtree root doesn't allow us to check whether the blobs were posted to the provided |
I'm trying to find where the current scheme was first proposed but I'm drawing a blank. IIRC @musalbas suggested it. Basically, in the current scheme rollup block producers post a new block to Ethereum and claim it uses a certain range or ranges of shares. The fun thing is those shares don't actually have to be a complete blob, or even from a single blob! The fraud proof would then prove that a single tx in the rollup is 1) in the data root (only requires proving the tx, not the whole block), and 2) is in the range(s) claimed (trivial). |
We can prove that a transaction was posted in the block, but how would we prove that that transaction is the right transaction? We will need to parse it to verify if the commitment and share index is the same as the one in the rollup header.
This means proving its position in the block? How would we do that? |
You don't actually need to prove anything about transactions, or blobs. That's the neat part. The rollup block producer just claims "here's this range in the Celestia block, that's the rollup block." That range could be anything. Doesn't have to be a transaction or a blob.
Something along the lines of celestiaorg/nmt#49 |
Even if you wanted to prove the commitment of the blob (without using a range), can't you also do that by using a blob inclusion proof - not a pfb proof? It would be less efficient than proving PFBs though. |
<!-- Please read and fill out this form before submitting your PR. Please make sure you have reviewed our contributors guide before submitting your first PR. --> ## Overview As per the decision in #142, we need to add the block size to the data root tuple. <!-- Please provide an explanation of the PR, including the appropriate context, background, goal, and rationale. If there is an issue with this information, please provide a tl;dr and link the issue. --> ## Checklist <!-- Please complete the checklist to ensure that the PR is ready to be reviewed. IMPORTANT: PRs should be left in Draft until the below checklist is completed. --> - [ ] New and updated code has appropriate documentation - [ ] New and updated code has new and/or updated testing - [ ] Required CI checks are passing - [ ] Visual proof for any user facing features like CLI or documentation updates - [ ] Linked issues closed with keywords --------- Co-authored-by: Rootul P <[email protected]>
As part of the efforts dedicated towards having an example of a Celestium, we will need to implement the following:
repeated bytes
decoding protobuf3-solidity#19The text was updated successfully, but these errors were encountered: