Only for review, no merge: Release es lookahead#387
Open
sfffaaa wants to merge 14 commits into
Open
Conversation
added 12 commits
June 17, 2026 17:41
The stable2503 treasury rework gates Treasury::spend behind SpendOrigin. es-dev-sync set SpendOrigin to council >1/2 (reusing RootOrTreasuryCouncilOrigin, which is the RejectOrigin threshold). Restore the pre-stable2503 ApproveOrigin threshold of a council 3/5 supermajority by introducing a dedicated RootOrTreasuryCouncilSpendOrigin (Root or EnsureProportionAtLeast<3,5>) and pointing SpendOrigin at it. RejectOrigin keeps the looser >1/2. Applied consistently across peaq, krest and peaq-dev. Rationale: 3/5 matches historical on-chain governance for spend approval; chosen over es-dev-sync's >1/2 per maintainer decision.
…nal binary
Two changes required to run the stable2503 binary against the live v1.7.2
runtime wasm (decoupled, binary-first upgrade):
1. Switch the parachain collator from slot_based to lookahead. slot_based
(elastic scaling) needs the CoreSelector/claim-queue runtime API that the
old 1.7.2 wasm does not expose; lookahead (async backing) is compatible.
Drops the SlotBasedBlockImport handle wiring throughout new_partial and
start_node, and spawns lookahead::run as an essential task.
2. Share one pubsub_notification_sinks Arc between MappingSyncWorker and the
EthPubSub RPC. They were each constructing their own sink, so
eth_subscribe("newHeads"/"logs") returned a sub ID but never delivered
notifications. Thread the worker's sink through FullDeps.
Rationale: ported as targeted hunks onto es-dev-sync (not a wholesale file
copy from the old lookahead branch) to preserve es-dev-sync's service-layer
improvements and avoid pulling in its command_sink/xcm_senders FullDeps fields.
…rade Live peaq mainnet is on spec 110 (verified via RPC); tag peaq-v0.0.111 (spec 111) exists but is not yet deployed. Bump to 112 so the stable2503 forkless upgrade is strictly greater than both the current on-chain value and the pending v0.0.111 release, avoiding a version collision. krest and peaq-dev not bumped here (krest live spec unverified; peaq-dev is non-mainnet).
Quality-pipeline back-half (code review / simplify / security / cross-AI via Codex) on the consolidation commits: PASS, no CRITICAL/HIGH. Only the LOW cosmetic findings are actioned here: - remove dead `// [TODO]` and `// collation_request_receiver: None,` left over from the slot_based->lookahead migration in node/src/parachain/service.rs - reword the treasury SpendOrigin comment in peaq/krest/peaq-dev to state the threshold decision accurately: the stable2503 base gated spends at council >1/2; deliberately tightened to council 3/5 here. (Replaces the loose "pre-stable2503 ApproveOrigin" wording.) Comment-only change; behaviour unchanged. Verified: cargo check -p peaq-node -p peaq-runtime -p peaq-krest-runtime -p peaq-dev-runtime exit 0.
…503 call reordering stable2503 reorders dispatchable call indices within several pallets - most critically pallet_treasury, where the same index maps to a different call (live spec 110: idx0=propose_spend; new: idx0=spend_local, idx2 approve_proposal -> spend, etc.). A client using cached pre-upgrade metadata would silently mis-encode/mis-dispatch these calls. Bumping transaction_version forces tooling to refresh metadata so reordered calls encode correctly (fail-loud instead of silent mis-dispatch). - peaq: transaction_version 1 -> 2 (spec_version already 112) - peaq-dev: transaction_version 1 -> 2, spec_version 107 -> 108 (a transaction_version bump must be paired with a spec_version bump) krest not changed (deferred this round). Evidence: metadata call-index diff of live spec-110 vs rig spec-112 (Treasury/ParachainSystem reordered; Assets/Balances/Council/XCM/Scheduler/Utility appended new calls).
NORMAL_DISPATCH_RATIO was deliberately raised 75% -> 90% (commit 7f26586 "90pc dispatch ratio and 10MB PoV size"), which raises the derived BlockGasLimit from ~60M to ~72M and the GAS_PER_SECOND-based estimate from ~15M to ~18M. The doc comment above GAS_PER_SECOND still cited the old 0.75 / 15M figures. Comment-only; no behaviour change.
PeaqMultiCurrenciesWrapper::withdraw (non-native branch) passed Preservation::Protect to fungibles::burn_from, which caps the reducible balance at the asset min_balance floor. A non-native withdraw that drains an account below min_balance (e.g. Zenlink local_withdraw during a swap) then fails with FundsUnavailable, whereas v1.7.2 succeeded and reaped the account (v1.7.2 burn_from hardcoded Expendable internally). Switch to Preservation::Expendable, matching the slash path in the same file and restoring v1.7.2 semantics. Reviewed (rust + security): no CRITICAL/HIGH. Reaping a non-native asset account on a legitimate withdraw is safe; native ED is 0, the relevant floor is the per-asset min_balance.
PeaqMultiCurrenciesOnChargeTransaction::can_withdraw_fee is invoked by pallet-transaction-payment in the validate phase (mempool), which must be side-effect-free. It called ensure_can_withdraw, which executes a real Zenlink swap (inner_swap_assets_for_exact_assets). withdraw_fee (in the prepare phase) also calls ensure_can_withdraw, so a foreign-currency-paid extrinsic swapped twice (double-swap) and mutated state during mempool validation. Use the read-only check_currencies_n_priorities (balance check + AMM quote via get_amount_in_by_path, no swap) in can_withdraw_fee. The real swap happens once, in withdraw_fee during prepare, matching the standard substrate can_withdraw -> withdraw contract. Also drop the stale TODO. Reviewed (rust + security): both SAFE/CORRECT, no fee-evasion path; the validate->prepare TOCTOU is inherent to the substrate fee model and handled (prepare failure drops the tx). Known pre-existing MEDIUM (not introduced here): can_withdraw_fee checks `fee` while withdraw_fee charges `fee + eot_fee`, so an account exactly at the boundary can pass validate but fail prepare; follow-up to pass the EoT-adjusted fee.
MAXIMUM_BLOCK_WEIGHT is WEIGHT_REF_TIME_PER_SECOND*2 (2s), not 500ms, and NORMAL_DISPATCH_RATIO is 90% in all three runtimes, so the block EVM gas limit is GAS_PER_SECOND(40M)*2.0*0.90 = 72,000,000 (matches on-chain gasLimit). peaq-dev/krest comments additionally still said 75% -> 15M, inconsistent with the 90% code; corrected to 72M as well.
…_currency The PCPC helper is named like a read-only check (per the Substrate/ORML ensure_can_withdraw convention) but actually EXECUTES a DEX swap — that misleading name is what let the double-swap bug (calling it from the side-effect-free validate phase) slip in originally. Rename it to state the mutation plainly; the read-only counterpart stays check_currencies_n_priorities. Behavior-neutral (default trait method + its single caller in withdraw_fee); ORML MultiCurrency::ensure_can_withdraw is unrelated and untouched.
The parachain importer used sc_service::new_full_parts (proof recording off) while the proposer uses ProposerFactory::with_proof_recording. That asymmetry made cumulus-pallet-weight-reclaim write a different frame_system::BlockWeight on author vs importer, which changed the intermediate state root that frontier embeds into the fron digest; every non-author node then failed execute_block final_checks (Digest item must match that calculated) on any block containing a user extrinsic. Restore new_full_parts_record_import(.., true), dropped in 0803694 while porting the lookahead collator (originally added in 6800a32). Client-only fix, no runtime change.
neutrinoks
requested changes
Jul 8, 2026
neutrinoks
left a comment
neutrinoks
left a comment
Contributor
There was a problem hiding this comment.
Krest spec version also needs to be increased ☝️
Contributor
There was a problem hiding this comment.
If the runtime changes as well, the spec version needs to be increased as well, right? In peaq runtime that change done...
added 2 commits
July 8, 2026 08:03
Update the krest network's comment + version even we won't use this anymore, but we can remove this runtime in our next release
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
2 participants
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.
No description provided.