Skip to content
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

Refactoring the bad ER tracking and the fraud proof trigger #2329

Merged
merged 7 commits into from
Dec 20, 2023

Conversation

NingLin-P
Copy link
Member

@NingLin-P NingLin-P commented Dec 14, 2023

close #2286

This PR comes with changes of:

Code contributor checklist:

It will be used in the upcoming commits to get onchain receipt hash and
compare with the operator's local receipt hash

Signed-off-by: linning <linningde25@gmail.com>
Signed-off-by: linning <linningde25@gmail.com>
No more checking all ER and fraud proof in the block body and not relying
on the aux storage for tracking bad ER.

This commit als come with a improvement that when the consensus chain switch
to a new best fork, we only check the best block instead of all new blocks in
the fork

Signed-off-by: linning <linningde25@gmail.com>
…d proof trigger

Signed-off-by: linning <linningde25@gmail.com>
Signed-off-by: linning <linningde25@gmail.com>
It test how the operator handle 2 bad ER at once when the last ER use the previous
ER as parent ER

Signed-off-by: linning <linningde25@gmail.com>
Copy link
Member

@vedhavyas vedhavyas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering why remove the exisiting fraud proof generation code and rewrite the same instead of making some changes to re-use exisiting one since the only thing that changed is the way we detect the mismatches. This would have reduced some noise IMO.

Overall make sense. Left some questions/nits

test/subspace-test-service/src/lib.rs Outdated Show resolved Hide resolved
@@ -1855,6 +1855,8 @@ impl<T: Config> Pallet<T> {
}

/// Returns the block number of oldest execution receipt.
// FIXME: the `oldest_receipt_number` may not be correct if fraud proof is submitted
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe the way we derive this is not stable. We should instead track the confirmed domain block number and then return the immediate uncornfirmed block's ER as oldest receipt number instead of using head_receipt number since, like you mentioned, is prone to FraudProof pruning

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, we should explicitly track either the confirmed domain block number or the oldest receipt number (which does not make much difference IMO) instead of deriving from the head receipt number.

Signed-off-by: linning <linningde25@gmail.com>
@NingLin-P NingLin-P added this pull request to the merge queue Dec 20, 2023
Merged via the queue into main with commit b787130 Dec 20, 2023
10 checks passed
@NingLin-P NingLin-P deleted the refactoring-bad-er-tracking branch December 20, 2023 14:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactoring the bad ER tracking and the fraud proof trigger
2 participants