-
Notifications
You must be signed in to change notification settings - Fork 511
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
Improve candidate validation robustness for missing relay chain blocks #579
Closed
eskimor opened this issue
Aug 12, 2023
· 1 comment
· Fixed by #1190 · May be fixed by paritytech/polkadot#7646
Closed
Improve candidate validation robustness for missing relay chain blocks #579
eskimor opened this issue
Aug 12, 2023
· 1 comment
· Fixed by #1190 · May be fixed by paritytech/polkadot#7646
Comments
eskimor
changed the title
Improve dispute participation robustness by making the upcoming session available
Improve dispute participation robustness by exposing upcoming session information
Aug 12, 2023
Indeed. Past and upcoming session info should be predetermined, therefore we should make runtime API queries according to some recent relay-chain block we do have as opposed to making runtime API queries based on the candidate's relay-parent. |
eskimor
changed the title
Improve dispute participation robustness by exposing upcoming session information
Improve candidate validation robustness for missing relay chain blocks
Aug 28, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We just had an issue with the following logs:
Not being able to participate in a dispute because we could not find the relay parent is not ideal. We want to be able to get backers slashed, even if their malicious candidate only resides on some dead fork. dispute-coordinator and dispute-distribution are already pretty robust against issues caused by being out of sync. In particular we pre-fetch session info based on active leaves. Therefore, if the exact relay parent of a candidate was missing, we would still succeed in fetching needed session information. The above revealed a weakness in fetch execution environment parameters, so this should be made as robust.
Subsystems requesting candidate validation all already know the SessionIndex and can just pass it into candidate-validation, avoiding the need to fetch it there, removing errors for pruned/not yet available relay chain blocks.
Candidate validation can then use any current leaf to fetch any data for that
SessionIndex
it might need to do the actual validation.The text was updated successfully, but these errors were encountered: