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

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
Copy link
Member

eskimor commented Aug 12, 2023

We just had an issue with the following logs:

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.

@eskimor 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
@rphmeier
Copy link
Contributor

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.

@Sophia-Gold Sophia-Gold transferred this issue from paritytech/polkadot Aug 24, 2023
@eskimor 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
Labels
None yet
Projects
No open projects
2 participants