QuantumAi Blockchain and Aethermind Update

BlockArtica1 pts1 comments

V121, four bonded validators, and Aether-Mind on GPU · QuantumAI Blockchain | Quantum Blockchain<br>Network notice:Chain RPC unreachable— Public node not responding. We monitor; try again shortly.status.qbc.network ↗

← All postsSubstrate runtime v121 landed on chain 3303 in a single block this afternoon. The code change is small: thirty lines in runtime/src/lib.rs. The on-chain effect is large. The MinAuthoritySetSize floor that blocked the election pallet drops from 10 to 4, the four validators bonded earlier today get elected with qbcElection.submit_elected_set(era=0, [alice, bob, charlie, dave], total_stake=40_000 QBC), and the AuraValidatorSet trait that gates QVM-anchor, Aether-anchor, and model-registry submissions now reads the live bonded set instead of the hardcoded Aura authorities. The chain is permissionless at the runtime-read level for the first time.

Commit 920bcbc7 on presale/v1 pushed to origin, qai-aether, and qai-substrate. WASM artefact 479,551 bytes, SHA-256 241d1fd61c101ad415cc443e39e06e4531fc54bd6195b6df959665449a66ae35.

What was missing before v121

Two interlocking things.

First, pallet-qbc-election::submit_elected_set had a MinAuthoritySetSize = 10 floor. The chain has had three Aura validators (Alice, Bob, Charlie) for months. The election pallet would reject any submitted set below the floor with InsufficientCandidates. We could bond candidates in pallet-qbc-staking, but there was no way to actually elect them.

Second, the AuraValidatorSet trait that other pallets depend on (qvm-anchor for state-root submissions, aether-anchor for attention attestations, model-registry for checkpoint attestations) read its set from pallet_aura::Authorities. That storage was populated at genesis with a hardcoded three-validator set. New bonded candidates never appeared there. Even if you bonded fifty validators tomorrow, the pallets that gate on validator identity would still see only the original three.

V121 cuts through both. The floor drops to four, matching what we have. The trait now reads pallet_qbc_staking::Validators::iter_keys(). Whoever bonds and validates is in the set the gating pallets see.

The runtime change

Three edits in substrate-node/runtime/src/lib.rs. The full diff is 18 insertions, 7 deletions.

// spec_version 120 -> 121<br>spec_version: 121,

// MinAuthoritySetSize 10 -> 4<br>pub const QbcMinAuthoritySetSize: u32 = 4;

// AuraValidatorSet rewired to read the live bonded set.<br>// Falls back to the legacy Aura authorities if staking is empty,<br>// so qvm-anchor / aether-anchor / model-registry keep accepting<br>// submissions through any transient state at the upgrade boundary.<br>impl frame_support::traits::GetVec> for AuraValidatorSet {<br>fn get() -> Vec {<br>use sp_runtime::traits::IdentifyAccount;<br>let bonded: Vec =<br>pallet_qbc_staking::pallet::Validators::::iter_keys().collect();<br>if !bonded.is_empty() {<br>return bonded;<br>pallet_aura::Authorities::::get()<br>.into_inner()<br>.into_iter()<br>.map(|aura_id| {<br>let inner: sp_core::sr25519::Public = aura_id.into();<br>sp_runtime::MultiSigner::Sr25519(inner).into_account()<br>})<br>.collect()

The fallback to the legacy Aura set matters. If the staking map is unexpectedly empty for a few blocks around the upgrade (because of state migration timing, or because someone calls chill then re-bonds), the dependent pallets shouldn't reject everything. The fallback gives a safe transition path.

That is the entire substantive change. WASM rebuilt, sudo submitted system.setCode() via //Alice, the upgrade finalised in one block.

Why this v121 is not an Aura-to-BABE swap

The original plan called for the full Aura-to-BABE engine swap as part of v121: replace pallet-aura with pallet-babe, add pallet-session, write an OnRuntimeUpgrade migration to kill Aura storage and seed BABE state, modify node/src/service.rs to use BABE's block import. Four to eight hours of careful Rust work with real chain-halt risk if migration is wrong.

Reading the runtime carefully changed my mind. The chain's pallet_timestamp::Config::OnTimestampSet is set to () with the comment "VQE mining controls block timing, not Aura slots. Blocks are authorized by VQE proofs, not Aura authority signatures." The real block production engine is pallet-qbc-consensus plus VQE mining via the --mine flag. Aura is a name registry, decorative in this architecture. There is no standard pallet-session in the runtime; a custom pallet-qbc-session sits at index 14 and would conflict with the standard one without architectural redesign.

A BABE engine swap in this chain would be ceremony, not function. BABE's VRF slot leadership doesn't matter when VQE already controls block production. The genuine permissionless step is the validator-set read path. That is what shipped.

The full BABE question stays open for v122 or later, if and when there's a real reason for VRF slot leadership replacing VQE-mining-as-Sybil-resistance. It's a multi-day architectural decision, not a code change.

Four bonded validators in one...

pallet aura bonded chain babe validators

Related Articles