You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2023-08-10 22:59:45.367 WARN tokio-runtime-worker parachain::dispute-coordinator: Candidate 0x340ca58da210113c62351725f34a031924772af9b2967987974344bc1a0e2bec considered invalid: BadParent
2023-08-10 22:59:45.366 WARN tokio-runtime-worker parachain::runtime-api: cannot query the runtime API version: Api called for an unknown Block: Header was not found in the database: 0x67541ead0a80909b695bd5d0a4ad61422e7a927b541a91adf0004059ffdc02a7
2023-08-10 22:59:45.366 WARN tokio-runtime-worker parachain::candidate-validation: Failed to acquire executor params for the session validation_code_hash=0x9bb8ab583eaf6a4caa1b0c57c123a697b0dfe7a5935ffff7726b9f359ccc59ad para_id=Id(2123)
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:
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
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: