-
Notifications
You must be signed in to change notification settings - Fork 247
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
Conversation
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>
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.
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
@@ -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 |
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.
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
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.
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>
close #2286
This PR comes with changes of:
Code contributor checklist: