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
{{ message }}
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
We'll need the runtime to keep track of all included candidates as well as the core index they occupied when they became available as part of the approval lottery ticket checking procedure on-chain. The shared module is a natural candidate for this.
In fact, the disputes runtime PR (#2947) already included a mapping of included blocks based on candidate hash and session index, so that will become obsolete after the implementation of this issue is complete.
This issue will have 2 parts:
Add a mapping of all included candidates to the shared module, to be filled out as part of the paras_inherent processing pipeline. This should keep all candidates for recent sessions, and should be designed in such a way that pruning of ancient sessions' data is performed gradually over the course of many blocks. Attempting to delete all included candidates in one block will become a scaling bottleneck and will prove to be an issue.
Remove the Included mapping from the Disputes runtime module and change it to rely on the shared module's mapping instead.
The text was updated successfully, but these errors were encountered:
Part of #3463 .
We'll need the runtime to keep track of all included candidates as well as the core index they occupied when they became available as part of the approval lottery ticket checking procedure on-chain. The
shared
module is a natural candidate for this.In fact, the disputes runtime PR (#2947) already included a mapping of included blocks based on candidate hash and session index, so that will become obsolete after the implementation of this issue is complete.
This issue will have 2 parts:
shared
module, to be filled out as part of theparas_inherent
processing pipeline. This should keep all candidates for recent sessions, and should be designed in such a way that pruning of ancient sessions' data is performed gradually over the course of many blocks. Attempting to delete all included candidates in one block will become a scaling bottleneck and will prove to be an issue.Included
mapping from theDisputes
runtime module and change it to rely on theshared
module's mapping instead.The text was updated successfully, but these errors were encountered: