This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Go-ahead signal makes validation upgrade delay of less than 2 invalid #4248
Assignees
Labels
I4-annoyance
Code behaves within expectations, however this “expected behaviour” itself is at issue.
I8-refactor
Code needs refactoring.
Comments
rphmeier
added
I8-refactor
3 tasks
2 tasks
pepyakin
added a commit
that referenced
this issue
Dec 22, 2021
Closes #4248 Impose additional constraint on configuration consistency: `validation_upgrade_delay` should not be less than or equal to 1. See the original issue for more details.
1 task
pepyakin
added a commit
that referenced
this issue
Dec 22, 2021
Closes #4248 Impose additional constraint on configuration consistency: `validation_upgrade_delay` should not be less than or equal to 1. See the original issue for more details.
pepyakin
added a commit
that referenced
this issue
Dec 24, 2021
Closes #4248 Impose additional constraint on configuration consistency: `validation_upgrade_delay` should not be less than or equal to 1. See the original issue for more details.
pepyakin
added a commit
that referenced
this issue
Dec 27, 2021
Closes #4248 Impose additional constraint on configuration consistency: `validation_upgrade_delay` should not be less than or equal to 1. See the original issue for more details.
pepyakin
added a commit
that referenced
this issue
Dec 28, 2021
Closes #4248 Impose additional constraint on configuration consistency: `validation_upgrade_delay` should not be less than or equal to 1. See the original issue for more details.
pepyakin
added a commit
that referenced
this issue
Dec 28, 2021
Closes #4248 Impose additional constraint on configuration consistency: `validation_upgrade_delay` should not be less than or equal to 1. See the original issue for more details.
drahnr
pushed a commit
that referenced
this issue
Jan 4, 2022
Closes #4248 Impose additional constraint on configuration consistency: `validation_upgrade_delay` should not be less than or equal to 1. See the original issue for more details.
Wizdave97
pushed a commit
to ComposableFi/polkadot
that referenced
this issue
Feb 3, 2022
Closes paritytech#4248 Impose additional constraint on configuration consistency: `validation_upgrade_delay` should not be less than or equal to 1. See the original issue for more details.
3 tasks
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Changes here are to update the
HostConfigurationdocumentation, the setters, and any places whereHostConfigurationis defined for testnets.Related to #4246.
With go-ahead signals, code upgrades are meant to be applied on the first parablock included with a relay-parent >= the first relay chain block where the go-ahead signal was set.
The go-ahead signal is incompatible with delay '0' because that implies instant upgrades. In the old system, delay '0' meant that the code upgrade was applied as soon as the parablock announcing it was included. With go-ahead signals, this is the earliest point where the go-ahead can be set, so the go-ahead logic is incompatible with the old system.
The go-ahead signal is incompatible with delay '1' because a block built on top of relay-parent X would be included in relay-parent X+2, at which point a block with relay-parent X+1 could be backed. The earliest time a go-ahead signal can be set is at relay block X+2, so the relay chain would expect the block with relay-parent X+1 to set the code even though it hadn't seen the go-ahead signal.
Actually, if we extend to contextual execution (#3779), any
validation_upgrade_delayless than or equal to some parametermax_relay_parent_ageis disallowed. We can think of the current system as havingmax_relay_parent_age = 1.The text was updated successfully, but these errors were encountered: