fix(paseo): use FixedVelocityConsensusHook for 6s block time (spec 9263)#4050
Merged
Conversation
The Paseo runtime's parachain_system::Config used the legacy `ExpectParentIncluded` consensus hook (kept for standalone launch). That hook requires each block's parent to already be included by the relay chain and has no unincluded segment, so it cannot pipeline blocks for async backing. After the 12s->6s upgrade (spec 9262) Paseo stalled at 12s with hundreds of collator panics (`expected parent to be included`, `Slot must increase`) and reorgs. Switch to the `FixedVelocityConsensusHook` already defined in the file (parameterised by RELAY_CHAIN_SLOT_DURATION_MILLIS / BLOCK_PROCESSING_VELOCITY / UNINCLUDED_SEGMENT_CAPACITY) — the same hook the heima runtime uses. heima mainnet was never affected. Also remove the one-shot block_time_6s migrations: they already ran and completed on Paseo at spec 9262 (verified on-chain: OnePassRescale guard set, staking Round.length 10->20, score-staking interval ->100800, vesting per_block halved, MBM done). The heima runtime keeps its copy for the still- pending mainnet upgrade. spec_version 9262 -> 9263.
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
`generate-release-notes.sh` extracted the runtime version with `grep spec_version`, which also matched the migration comment line that mentions "spec_version 9262". That pulled the comment text into the version field, so release notes rendered: version : // (spec_version 9262). Remove in the release after this one. ... 9262 Anchor the grep to the actual `spec_version:` field (leading whitespace + colon) and take the first match, so only the number is emitted.
`cargo clippy --workspace -- -D warnings` (the parachain-check CI job) failed on the nested `Option<BoundedVec<VestingInfo<..>, MaxVestingSchedulesGet<T>>>` return type of `VestingRescaleMigration::rescale_account`. Introduce a `ScheduleList<T>` type alias for the account's schedule list and use it for both the argument and return type. No behaviour change.
The 12s->6s change doubled YEARS (and thus BLOCKS_PER_YEAR = YEARS), so with the mock's fixed DefaultBlocksPerRound the rounds-per-year doubled and the per-round inflation derived from the annual rate halved. Three pallet tests hard-coded the old (12s) per-round values and failed: - set_blocks_per_round_event_emits_correctly: from_parts(926) -> 463 - set_inflation_event_emits_correctly: 57/75/93 -> 29/38/47 - set_inflation_storage_updates_correctly: 57/75/93 -> 29/38/47 Values updated to what the code now computes (annual rates unchanged). This was fallout from the block-time constant change that the earlier PR missed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
After the 12s→6s upgrade (spec 9262), Paseo stalled at 12s with hundreds of collator panics and reorgs:
assertion left == right failed: expected parent to be includedSlot must increase,set_validation_data inherent needs to be presentThe runtime upgrade itself succeeded — spec is 9262 and every migration ran correctly on-chain (verified via RPC: OnePassRescale guard set, staking
Round.length10→20, score-stakinginterval→100800, vestingper_blockhalved +starting_blockrebased, MBM done). The chain simply can never reach 6s because of the consensus hook.Root cause
Paseo's
parachain_system::Configused the legacyExpectParentIncludedhook (kept for standalone launch). That hook requires each block's parent to already be included by the relay chain and supports no unincluded segment, so it cannot pipeline blocks for async backing — at 6s it deadlocks against the relay's own 6s cadence and panics. The file already defined the correctFixedVelocityConsensusHook(same one the heima runtime uses) but it was never wired in.heima mainnet was never affected — it already uses
FixedVelocityConsensusHook.Fix
type ConsensusHook = ExpectParentIncluded→ the existingFixedVelocityConsensusHook(parameterised byRELAY_CHAIN_SLOT_DURATION_MILLIS/BLOCK_PROCESSING_VELOCITY/UNINCLUDED_SEGMENT_CAPACITY).block_time_6smigrations from Paseo — they already ran at 9262. The heima runtime keeps its copy for the still-pending mainnet upgrade.spec_version9262 → 9263.Why try-runtime didn't catch this
try-runtime
on-runtime-upgradeexercises the migration hooks and per-blocktry_state, which all passed. It does not simulate the continuous block-production / consensus-hook flow, so a hook↔velocity mismatch only surfaces during real authoring. This is exactly what the Paseo canary caught before mainnet.Verification
cargo check -p paseo-runtimeandcargo fmt --checkpass. After this upgrade is enacted on Paseo, confirm block interval drops to ~6s and the panics/reorgs stop.