This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
New Parachains Runtime API tailored for backing. #3700
Labels
I10-optimisation
An enhancement to provide better overall performance in terms of time-to-completion for a task.
Right now during candidate validation for backing we query persisted validation data. We do it once with the assumption that the core is free and if the hash of persisted validation data does not match the hash found in the candidate we try once more with assumption that the current candidate occupied the core is enacted. Once we figured out what persisted validation data matches we query runtime API for the current validation code. This amounts to 3 runtime API requests which seems to be inefficient.
Furthermore, during working on #3655 we've realized that we actually need to get the validation code hash that parachain currently has. This functionality exists but is not exposed as a runtime API.
In order to solve two problems at once I propose a new one-stop shop API which will be tailored specifically for backing.
Next follows a rough description of the API:
The API accepts the
para_id
,expected_persisted_validation_data_hash
and returns thevalidation_code_hash
and the preimage ofpersisted_validation_data
. The API is supposed to be called against thedescriptor.relay_parent
.The implementation will do a check:
Obtain the
persisted_validation_data
for the givenpara_id
and hash it. If the hash matches the passedexpected_persisted_validation_data_hash
then query the current validation code hash and return the persisted validation data preimage.This check is performed twice actually: first without force enacting the core and then with it. If the core is not occupied we can skip the second check since it won't do any difference. If the match was found on the first attempt the implementation should return immediately.
The text was updated successfully, but these errors were encountered: