review: GRANDPA authority derivation from mining activity#418
review: GRANDPA authority derivation from mining activity#418Copilot wants to merge 1 commit intopr/add-multigrandpa-voter-supportfrom
Conversation
|
@copilot what makes you think grandpa auto rotates the set id? here's the grandpa pallet // This file is part of Substrate. // Copyright (C) Parity Technologies (UK) Ltd. // Licensed under the Apache License, Version 2.0 (the "License"); //! GRANDPA Consensus module for runtime. #![cfg_attr(not(feature = "std"), no_std)] extern crate alloc; // Re-export since this is necessary for use alloc::{boxed::Box, vec::Vec}; mod default_weights; #[cfg(any(feature = "runtime-benchmarks", test))] pub use equivocation::{EquivocationOffence, EquivocationReportSystem, TimeSlot}; pub use pallet::*; #[frame_support::pallet] } pub trait WeightInfo { /// Bounded version of /// A stored pending change. /// Current state of the GRANDPA authority set. State transitions must happen in impl<T: Config> Pallet { } impl<T: Config> sp_runtime::BoundToRuntimeAppPublic for Pallet { impl<T: Config> OneSessionHandler<T::AccountId> for Pallet } |
I was wrong about this. My assumption came from standard Substrate runtimes that use Without I retract finding #1 from the review. The code is correct as-is. Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
Code review for
feat(mining-slot): derive GRANDPA from recent mining activitybefore marking the PR public.Findings
🔴 Needs Clarification —
CurrentSetIddouble-increment riskIn both
runtime/argon/src/lib.rsandruntime/canary/src/lib.rs,pallet_grandpa::CurrentSetIdis manually incremented immediately afterschedule_change(..., delay=0, ...):If
pallet_grandpaalso incrementsCurrentSetIdwhen it applies the delayed change (standard substrate behavior), the set ID advances by 2 per rotation instead of 1 — causing GRANDPA message signature mismatches as voters and on-chain state diverge. This could be the root of the historical drift thatgrandpa_set_id_patch.rswas patching. If the pallet does not auto-increment on apply and this is intentional, a comment to that effect would help maintainability.🔴 Needs Clarification — Commented-out
GrandpaStateOverridergrandpa_set_id_patch.rsis still present but the wiring inservice.rs:96–99is commented out. Nodes syncing mainnet/testnet from genesis won't have the historical set ID overrides applied and may stall. Intentionally disabled because the manual increment above now keeps IDs in sync from a known point forward?🟡 Minor —
std::thread::sleepinspawn_blockingasync block🟡 Minor — Activity weight is per-cohort-entry, not per-block-won
collect_recent_operator_weightsgives each miner+1iflast_win_blockfalls within the window, regardless of total blocks won. The module doc says "weighted by recent activity" — worth clarifying that "activity" means "had any win in window per cohort slot", not "proportional to wins".🟢 Liveness fallback semantics (not a bug, worth documenting)
The fallback to the extended window only fires if it yields strictly more operators than the primary window. If both return the same count and that count is still below
minimum_authorities_needed, the fallback is skipped andderive_authorities_from_weightshandles it via equal-weight. This is correct but non-obvious.What Looks Good
collect_recent_operator_weightsuses>(not>=), correctly including operators whose last win was exactly at the window edge✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.