-
Notifications
You must be signed in to change notification settings - Fork 244
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
Implement the fraud proof v2 processing #1932
Conversation
…r testing Every FraudProof should have a bad_receipt_hash field (except BundleEquivocationProof), which is used during the fraud proof processing to identify the fraudulent ER, this commit also add some misc dummy fraud proof that used for testing. Signed-off-by: linning <linningde25@gmail.com>
This validation ensure the fraud proof can't target the genesis receipt and the targetted receipt must exist in the block tree, which also ensure the fraud proof is submitted to the right fork of the consensus chain. Signed-off-by: linning <linningde25@gmail.com>
This storage item is used to keek track of the immediate descendants of an ER, it is used during fraud proof processing to prune all the descendants of the targetted fraudulent ER. This storage item can be removed after this task #1731 is implemented, by then every ER should only have one immediate descendant Signed-off-by: linning <linningde25@gmail.com>
The processing includes 1. remove the fraudulent ER and all of its descendants from the block tree 2. protentially update the heade receipt number 3. slash the operator who have submitted the pruned fraudulent ER Signed-off-by: linning <linningde25@gmail.com>
…sts to pallet_domains::tests These utilities will also be used by the upcoming fraud proof test, so moving them to an upper module to share Signed-off-by: linning <linningde25@gmail.com>
Signed-off-by: linning <linningde25@gmail.com>
The receipt may already been pruned if there is fraud proof being processed and the is reverted. Test cases is added accordingly. This commit also add TODO for a non-trival to fix issue, and it is intended to fix with #1731 Signed-off-by: linning <linningde25@gmail.com>
// FIXME: the following check is wrong because the ER at `to_prune` may not necessarily go through | ||
// the whole challenge period since the malicious operator can submit `NewBranch` ER any time, thus | ||
// the ER may just submitted a few blocks ago and `receipts_at_number` may contains more than one block. | ||
// | ||
// In current implementatiomn, the correct finalized ER should be the one that has `BlockTreePruningDepth` | ||
// lenght of descendants which is non-trival to find, but once https://github.com/subspace/subspace/issues/1731 | ||
// is implemented this issue should be fixed automatically. | ||
if receipts_at_number.len() != 1 { | ||
return Err(Error::MultipleERsAfterChallengePeriod); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The previous check of MultipleERsAfterChallengePeriod
is wrong and seems non-trivial to fix with the current design, but it should be fixed once we implement #1731 cc @vedhavyas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explained in more detail in #1934
Signed-off-by: linning <linningde25@gmail.com>
… into fraud-proof-processing
close #1529
This PR implements the fraud proof v2 processing, which includes:
NOTE: there is a
DomainBlockDescendants
storage item introduced in this PR to keep track of the immediate descendant of an ER, and it is used to determine and remove all of the descendants of the targetted ER. This tracking can be removed once #1731 is implemented because by then every ER should only have one immediate descendant.Recommend to review this PR commit by commit.
Code contributor checklist: