9. Dynamic Sharding

9.1 Implemented Scope​

quantos/src/sharding/ contains a configurable ShardManager, address-prefix shard mapping, load metrics, rebalance actions, cross-shard coordination, state-migration helpers, self-healing logic, and a STARK-accelerated module. The parallel scheduler also supports per-shard queues and worker execution.

These components establish a sharding design and executable local behavior. They do not by themselves prove that a deployed network maintains atomicity, availability, or linear throughput during churn.

9.2 Configuration​

The default ShardingConfig includes configurable minimum and maximum shard counts, split/merge thresholds, a rebalance cooldown, and a load-averaging window. Defaults are implementation values, not mainnet constants. The code maps an address prefix to a shard range; the mapping and topology version must be coordinated by the network.

9.3 State Migration and Cross-Shard Safety​

State migration and cross-shard operations require source/target coordination, authorization, replay protection, timeout handling, and a clear commit/rollback invariant. The repository includes code for these concerns, but the current whitepaper must not claim a universal two-phase-commit or STARK-verified guarantee unless the exact deployed path verifies it. Multi-node tests must cover crashes, retries, delayed messages, conflicting migrations, and validator-set changes.

9.4 Scaling Claim​

Independent shard queues and parallel execution can increase capacity for localized workloads. Cross-shard traffic, hot accounts, state synchronization, signature verification, and rebalancing reduce that capacity. Aggregate TPS is therefore a benchmark result, never a direct multiplication of a local shard target by the configured shard count.

9.5 Mainnet Requirements​

A normative sharding specification must fix shard assignment, topology updates, committee assignment, migration phases, cross-shard finality, failure recovery, maximum concurrency, and data-availability obligations. The current module is an experimental scaling subsystem pending that specification.

9.4 Cross-Shard Coordination (Experimental)​

The repository contains cross-shard coordination and finalization paths. Atomic commit and zk-STARK verification are configuration- and path-dependent and must be validated in multi-node tests before being described as protocol guarantees:

Source Shard                         Destination Shard
     │                                      │
     │  1. Lock funds on source             │
     │  2. Emit CrossShardTx + STARK proof  │
     │ ───────────────────────────────────▶ │
     │                                      │ 3. Verify STARK proof of lock
     │                                      │ 4. Credit funds on destination
     │  5. Confirm                          │
     │ ◀─────────────────────────────────── │
     │  6. Finalize (release lock record)   │
     │                                      │

Key safeguards:

• Proof and authenticity checks: The exact deployed path must demonstrate what is verified locally and what is trusted from the source shard; the presence of enable_zk_proofs is not sufficient evidence of an end-to-end guarantee.
• Timeouts and rollback: Each cross-shard transaction has a timeout_ms deadline and a max_retries bound. If the destination never confirms, the source automatically rolls back the lock, returning funds to the sender.
• Per-sender DoS limits: At most MAX_PENDING_PER_SENDER = 100 outstanding cross-shard transactions per account, and a configurable max_pending_per_shard, prevent a single actor from saturating the cross-shard channel.

Because cross-shard transactions carry this additional commitment overhead, they are inherently more expensive than intra-shard transactions. This is the principal reason the aggregate-throughput figure in the Performance section is labelled theoretical: real-world throughput depends on the ratio of intra-shard to cross-shard activity.

9.5 Rebalancing Helpers​

self_healing.rs contains rebalancing and migration helpers. Their availability, prediction quality, concurrency limits, and zero-downtime behavior require deployment-level validation:

• Target utilisation: The system targets TARGET_UTILIZATION = 80% per shard. A deviation beyond REBALANCE_THRESHOLD = 20% triggers rebalancing.
• Hotspot prediction: A lightweight predictive model uses recent per-shard load history to forecast emerging hotspots. This predictor is an advisory optimisation only — it influences when to proactively migrate, but every resulting migration still passes through the consensus-validated, 2-phase-commit re-sharding protocol of §9.3. No machine-learning output is ever part of the consensus-critical path.
• Concurrency control: At most MAX_CONCURRENT_MIGRATIONS = 3 migrations run simultaneously, and a MIN_REBALANCE_INTERVAL of 60 seconds prevents thrashing.
• Zero-downtime goal: Migrations are designed to keep affected accounts available, with the design target of bounded latency increase during migration rather than service interruption.

9.6 Proof-Oriented Acceleration​

The stark_accelerated module contains proof-oriented batch processing code. Whether a deployed network uses it for cross-shard verification, and what it proves, must be established from the active node path and benchmarked independently.