Paper deep dive
Closed-Loop Dynamic Validator Node Scaling in Private Substrate Blockchains Using Takagi-Sugeno Fuzzy Inference
Thandile Nododile, Ayinde M. Usman, Clement N. Nyirenda
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 7/10/2026, 2:45:30 AM
Summary
This paper introduces a Takagi-Sugeno fuzzy inference system for closed-loop dynamic validator node scaling in private Substrate blockchains. The controller monitors live blockchain parameters (block production time, block size, active node count) and outputs an efficiency score alongside scaling recommendations (Scale Up, Maintain, Scale Down). Triangular membership functions are empirically recalibrated to the testbed's observed operating range. Evaluated on a 10-node network processing smart water meter data, the system reduces scaling oscillations and maintains stable block production times compared to threshold-based baselines.
Entities (10)
Relation Signals (9)
Takagi-Sugeno fuzzy inference system → monitors → Block production time
confidence 95% · reads live blockchain parameters (block production time, block size, and active node count)
Takagi-Sugeno fuzzy inference system → monitors → Block size
confidence 95% · reads live blockchain parameters (block production time, block size, and active node count)
Takagi-Sugeno fuzzy inference system → monitors → Active node count
confidence 95% · reads live blockchain parameters (block production time, block size, and active node count)
Substrate blockchain → implements → GRANDPA finality
confidence 92% · running AURA consensus for block production and GRANDPA for deterministic finalisation.
Substrate blockchain → implements → AURA consensus
confidence 92% · running AURA consensus for block production and GRANDPA for deterministic finalisation.
Takagi-Sugeno fuzzy inference system → outputs → Efficiency score
confidence 90% · outputs a continuous efficiency score alongside a scaling recommendation
Takagi-Sugeno fuzzy inference system → outputs → Scaling recommendation
confidence 90% · outputs a continuous efficiency score alongside a scaling recommendation: Scale Up, Maintain, or Scale Down.
Takagi-Sugeno fuzzy inference system → →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Private blockchain networks run with fixed node configurations that cannot adapt to changing workload conditions. Too many nodes serving a light workload waste resources; too few nodes facing heavy demand slow block production and degrade finalisation. The right validator count is hard to determine, as it depends on overlapping factors that shift over time. This paper presents a Takagi-Sugeno (TS) fuzzy inference system that reads live blockchain parameters (block production time, block size, and active node count) and outputs a continuous efficiency score alongside a scaling recommendation: Scale Up, Maintain, or Scale Down. The controller uses triangular membership functions across three linguistic variables, evaluated through a complete 27-rule base with product t-norm aggregation. A key contribution is an empirical recalibration of the membership functions, anchoring linguistic terms to the observed operating range of the testbed rather than to theoretical extremes. The system is evaluated on a 10-node Substrate blockchain network storing real smart water meter data hashes from the Queensland Government open data portal. Statistical analysis across configurations of 4, 7, and 10 active nodes confirms that the controller produces distinct operational profiles reflecting each configuration's provisioning state. In closed-loop experiments, the controller autonomously adjusts validator participation in both directions, activating validators under rising load and removing them under over-provisioning, converging to the same stable equilibrium from both directions. Compared against three threshold-based baselines, it shows fewer scaling oscillations while maintaining comparable block production times. Results show that TS fuzzy inference can support autonomous validator management in private blockchain deployments, with stable scaling behaviour threshold approaches cannot match.
Tags
Links
- Source: https://arxiv.org/abs/2607.07901v1
- Canonical: https://arxiv.org/abs/2607.07901v1
Trouble viewing inline? Open PDF directly →
Full Text
45,679 characters extracted from source content.
Expand or collapse full text
Closed-Loop Dynamic Validator Node Scaling in Private Substrate Blockchains Using Takagi-Sugeno Fuzzy Inference Thandile Nododile, Ayinde M. Usman, Clement N. Nyirenda Abstract Private blockchain networks operate with fixed node configurations that cannot adapt to changing workload conditions. When too many nodes serve a light workload, resources are wasted; when too few nodes face heavy demand, block production slows and finalisation degrades. The right number of validator nodes is hard to determine, as it depends on multiple overlapping factors that shift over time. This paper presents a Takagi-Sugeno (TS) fuzzy inference system that reads live blockchain parameters, namely block production time, block size, and active node count, and outputs a continuous efficiency score alongside a scaling recommendation: Scale Up, Maintain, or Scale Down. The controller uses triangular membership functions across three linguistic variables, evaluated through a complete 27-rule base with product t-norm aggregation. A central methodological contribution is an empirical recalibration of the membership functions, anchoring the linguistic terms to the observed operating range of the testbed rather than to theoretical extremes. The system is evaluated on a 10-node Substrate blockchain network storing real smart water meter data hashes from the Queensland Government open data portal. Statistical analysis across validator configurations of 4, 7, and 10 active nodes confirms that the controller produces distinct operational profiles that correctly reflect each configuration’s provisioning state. In closed-loop experiments, the controller autonomously adjusts validator participation in both directions, activating validators under rising load and removing them under over-provisioning, and converges to the same stable equilibrium from both directions. Compared against three threshold-based baselines, it exhibits substantially fewer scaling oscillations while maintaining comparable block production times. The results demonstrate that TS fuzzy inference can support autonomous validator management in private blockchain deployments, with stable scaling behaviour that threshold approaches cannot match. †publicationid: pubid: 979-8-3195-0703-7/26/$31.00© 2026 IEEE I Introduction Blockchain technology provides a distributed, tamper-resistant ledger architecture suitable for applications requiring data integrity and auditability [12]. Devices in Internet of Things (IoT) environments generate large volumes of data that often lack inherent security. Blockchain offers secure, tamper-resistant storage for such sensor data across domains including healthcare, supply chain, and utility monitoring [5, 20]. Private blockchain networks, where validator participation is restricted to a known set of nodes, are particularly suited to enterprise IoT deployments that require auditability without the overhead of permissionless consensus [23]. Deploying these networks for IoT data management, however, introduces a tension: validator configurations are typically fixed, while IoT workloads vary with environmental conditions, time-of-day patterns, and device availability [21]. A configuration sized for peak load wastes computational resources during quiet periods, while one sized for average load cannot maintain acceptable block production times during demand spikes [7]. The challenge of adaptive node scaling is that the decision boundaries are not crisp. Network conditions exist on a continuum, and the appropriate scaling response depends on multiple interacting factors. When block production time is rising while block size is moderate and a subset of the available validators is already active, simple threshold rules cannot determine the correct action. Threshold-based controllers, common in distributed systems, react sharply at fixed cut-offs and tend to oscillate when input variables hover near the boundary. Fuzzy logic [25] addresses this through degrees of membership, allowing multiple inputs to contribute proportionally to a decision. The Takagi-Sugeno (TS) fuzzy inference system [22] is particularly suited to control applications: it produces crisp numerical outputs through weighted combinations of constant or linear functions and has been applied in networked control systems with communication constraints [26]. Prior work has established blockchain architectures for IoT data integrity [14], integrated Substrate with the InterPlanetary File System (IPFS) for off-chain storage [13], and demonstrated hybrid blockchain-IPFS solutions on smart water meter data [15]. These works addressed security and storage efficiency but used static validator configurations. Dynamic scaling of validator participation, driven by the live state of the chain, remains an open problem. This paper introduces a TS fuzzy inference system for closed-loop dynamic node scaling in private Substrate blockchains. The controller monitors block production time, block size, and active node count in real time, and triggers validator activation through verified peer discovery when scaling is recommended. A methodological contribution is the empirical recalibration of membership function parameters, anchored to the observed operating range of the testbed rather than to theoretical extremes. The controller is compared against three threshold-based baselines on identical workloads, with statistical tests characterising the trade-off between scaling stability and reactivity. The experimental evaluation focuses on three aspects of system behavior. First, it examines whether the controller’s recommendations align with the underlying blockchain operational state, such that it suggests Scale Up when the system is under-provisioned, Maintain when operating near target conditions, and Scale Down when over-provisioned. Second, it assesses whether scaling actions drive block production time toward the effective slot duration target corresponding to the current validator set size, indicating closed-loop convergence. Third, it evaluates the balance between stability and responsiveness by comparing whether the TS controller exhibits fewer scaling oscillations than threshold-based controllers while maintaining similar convergence performance. This paper’s contributions include: (i) a closed-loop dynamic node scaling system in which the TS controller triggers actual validator activation with peer-discovery verification; (i) an empirical recalibration of fuzzy membership functions with a generalisable anchoring rule and worked examples; (i) a closed-loop evaluation that demonstrates both scaling directions, with validator activation under rising load and deactivation under over-provisioning, each converging to the same equilibrium; and (iv) a comparative evaluation against three threshold-based baselines with Welch’s t-tests and Cohen’s d effect sizes. I Related Work I-A Blockchain Scalability and Node Management Blockchain scalability is a well-known challenge [28, 24], with the tension between decentralisation, security, and throughput [4] driving research into dynamic node management. Substrate provides a modular framework where consensus is separated into block authoring through the Authority Round (AURA) algorithm and finality through GHOST-based Recursive Ancestor Deriving Prefix Agreement (GRANDPA) [23]. These mechanisms operate on static, pre-configured rules; when transaction rates change, fixed validator configurations cannot adapt [7]. Protocol-level approaches such as sharding [10, 9] partition the network to process transactions in parallel but introduce cross-shard coordination complexity. He et al. [6] proposed a dynamic node selection approach for IoT blockchains using Graph Convolutional Networks, reducing latency but introducing computational overhead that may be prohibitive for resource-constrained edge deployments. Lightweight, adaptive mechanisms are still needed, that scale blockchain infrastructure without protocol modifications or heavy computation. I-B Fuzzy Logic for Distributed Resource Management Fuzzy set theory [25] extends classical set theory by allowing partial membership, providing a mathematical framework for handling uncertainty in decision-making. The TS fuzzy inference system [22] uses crisp mathematical functions as rule consequents, which approximates nonlinear systems efficiently. Kaur and Kaur [8] found Sugeno inference more computationally efficient than Mamdani for real-time control, and Zhao and Bose [27] showed that triangular membership functions balance simplicity with control accuracy. TS models have been applied to networked control systems with communication constraints [26]. Fuzzy logic has been applied to resource allocation in cloud and edge contexts [2]. Closer to blockchain, Alouache et al. [3] applied fuzzy logic to real-time reconfiguration in blockchain-based vehicular networks, and Omondi et al. [18] applied fuzzy evaluation to smart contract access control. These works target vehicular networks and access control policies rather than infrastructure-level validator node management in private blockchain deployments. I-C Blockchain-IoT Data Storage The growth of IoT deployments generates large volumes of sensor data requiring secure, distributed storage [20]. Blockchain offers data integrity through its append-only structure but faces storage and throughput limitations when processing continuous streams [5]. Combining blockchain with IPFS addresses storage constraints by keeping large data objects off-chain while recording content hashes on-chain [1], with applications across healthcare, supply chain, and industrial IoT [11]. A line of prior work has developed blockchain architectures for IoT data integrity, including a Substrate-based mechanism for smart water meter data [14], Substrate-IPFS integration for distributed storage [13], and a hybrid blockchain-IPFS solution [15]. These implementations achieved data security and storage efficiency but used static node configurations. The literature establishes that blockchain-IoT integration is well developed and that fuzzy logic effectively handles resource allocation under uncertainty. However, to the best of the authors’ knowledge, there is no existing work that applies fuzzy inference to closed-loop blockchain node orchestration. This paper addresses that gap. I System Design This section describes the architecture of the proposed adaptive node scaling system and the design of the TS fuzzy inference engine that produces its scaling recommendations. It develops the first two contributions stated in Section I: the closed-loop scaling architecture with peer-discovery verification (Section I-A, contribution i) and the empirical recalibration of the membership functions with a generalisable anchoring rule (Section I-B, contribution i). Algorithm 1 summarises the closed-loop procedure. I-A Architecture Overview The system comprises four functional layers, illustrated in Fig. 1. At the top is the IoT data ingestion pipeline that submits Secure Hash Algorithm 256-bit (SHA-256) hashes of sensor data files to the blockchain through a custom runtime pallet. Below it sits the private Substrate blockchain network, running AURA consensus for block production and GRANDPA for deterministic finalisation. The third layer is a JavaScript Object Notation Remote Procedure Call (JSON-RPC) monitoring bridge that extracts live network parameters from the chain. At the bottom sits the TS fuzzy inference engine, which processes the bridge’s three crisp inputs (block production time, block size, active node count) and outputs scaling recommendations. When a recommendation crosses the appropriate decision threshold for a sustained reading, the controller activates an additional validator, maintains the current configuration, or deactivates an excess validator. IoT Data LayerCSV files → SHA256 → H256Substrate Blockchain10 nodes, AURA + GRANDPA, custom palletJSON-RPC Bridgechain_getBlock, system_healthTS Fuzzy Controller27 rules → Efficiency + ActionScale Down / Maintain / Scale Upextrinsicsblock time, size, peers3 crisp inputs Figure 1: System architecture. IoT data files are hashed and submitted to the blockchain. The JSON-RPC bridge extracts live parameters, which the TS controller evaluates to produce scaling recommendations. The blockchain stores IoT data through a custom pallet that accepts SHA256 hashes of data files via a storeDataHash(H256) extrinsic. Raw data remains off-chain; only verification hashes are recorded on the ledger. Higher submission rates increase the number of extrinsics per block, which is one of the fuzzy controller’s monitored inputs. Algorithm 1 Closed-Loop Validator Node Scaling 1: n←n← initial active validators; cooldown←0cooldown← 0 2: loop 3: wait 5 s; read block time btbt, block size bsbs, node count n 4: fuzzify (bt,bs,n)(bt,bs,n) over all linguistic terms 5: compute firing strengths wiw_i (product t-norm) for the 27 rules 6: a←(∑iwici)/(∑iwi)a← ( _iw_ic_i )/ ( _iw_i ) action value 7: if cooldown>0cooldown>0 then 8: cooldown←cooldown−5cooldown← cooldown-5 suppress decisions 9: else if a≥0.7a≥ 0.7 and n<10n<10 then 10: activate validator; verify peer discovery 11: n←n+1n← n+1; cooldown←30cooldown← 30 Scale Up 12: else if a<0.3a<0.3 and n>4n>4 then 13: deactivate highest-numbered validator (SIGTERM) 14: n←n−1n← n-1; cooldown←30cooldown← 30 Scale Down 15: else 16: maintain configuration Maintain 17: end if 18: end loop I-B Input Variables and Membership Function Calibration Three linguistic variables capture the blockchain network’s operational state: block production time, block size, and active node count. Each variable is partitioned into three triangular membership functions (MFs), defined by three points [a,b,c][a,b,c] representing the left foot, peak, and right foot. Fig. 2 shows the calibrated MFs used in this work. Figure 2: Triangular membership functions for the three input variables after empirical calibration. Overlapping regions between adjacent terms enable smooth transitions in the controller’s output. The Block Time and Node Count partitions are anchored to the observed operating range of the testbed. The operating range of these variables depends on the underlying Substrate configuration and the data pallet used. A controller calibrated for one chain may produce flat or saturated outputs on another. The MF parameters are therefore anchored to the observed operating range rather than to theoretical extremes: • Block Time: MFs are anchored to the empirically observed range. Block times across configurations of 4, 7, and 10 active validators span 6.0 to 14.4 s, so the High triangle peaks at 14 s (the observed worst case) rather than at the theoretical upper bound from the slot duration formula. • Block Size: MFs are anchored to the empirical 50th and 95th percentiles of observed block sizes for the hash-storage pallet, mapping linguistic terms to the actual data distribution on the deployed chain. • Node Count: MFs use a fixed partition with the Many term peaking at 8 active validators (the realistic “fully scaled” point) rather than at the chain ceiling of 10. Table I lists the calibrated MF parameters used in this work. Table I shows worked examples of how the same anchoring rule transfers to chains with different slot durations. TABLE I: Calibrated Membership Function Parameters Variable Term Parameters [a, b, c] Block Time (s) Low [0, 0, 6] Medium [4, 9, 14] High [10, 14, 18] Block Size (MB) Small [0, 0, 0.005] Medium [0.002, 0.015, 0.030] Large [0.020, 0.040, 0.060] Node Count Few [1, 1, 4] Moderate [3, 5, 7] Many [6, 8, 10] TABLE I: Worked Examples: Anchoring Rule Across Deployment Configurations Deployment Slot Active/Auth. Effective Slot This work (4-of-10 baseline) 6 s 4/10 15.0 s This work (full topology) 6 s 10/10 6.0 s Fast Substrate (3 s slot) 3 s - 3.0 s Slow Substrate (12 s slot) 12 s - 12.0 s I-C Output Variables Each rule produces two zero-order TS constants: an Efficiency Score from 0 to 100 reporting how effectively the network utilises its resources, and an Action Value from 0 to 1 that maps to a scaling recommendation through threshold partitioning. An action value below 0.3 recommends Scale Down (decrease validator count by one), a value from 0.3 up to 0.7 recommends Maintain (no change), and a value of 0.7 or above recommends Scale Up (increase validator count by one). I-D Rule Base The rule base consists of 27 rules covering every combination of three input variables with three terms each (3×3×3=273× 3× 3=27). This completeness guarantees that no input state produces a default fallback response; every operating condition maps to a specific efficiency assessment and action recommendation. The rules encode domain knowledge about the relationship between blockchain operating conditions and appropriate scaling responses. When block time is Low and blocks are Small, the network has excess capacity and the action consequent favours Scale Down (e.g. R1: Low BT, Small BS, Few NC → Eff = 90, Act = 0.15, where BT denotes block time, BS block size, NC node count, Eff the efficiency score, and Act the action value). When block time is High and blocks are Large with Few active nodes, the network is severely under-provisioned and the consequent favours Scale Up (e.g. R25: High BT, Large BS, Few NC → Eff = 20, Act = 0.90). Balanced conditions favour Maintain (e.g. R14: Medium BT, Medium BS, Moderate NC → Eff = 70, Act = 0.50). Efficiency consequents span [20, 90] and action consequents span [0.15, 0.90], with the full rule set generated by interpolating between these anchor points along each input axis. I-E TS Fuzzy Inference The controller employs a zero-order TS fuzzy inference system [16]. Unlike Mamdani systems [17, 8], which represent outputs as fuzzy sets requiring centroid-based defuzzification, TS systems assign numerical constants as rule consequents and compute the final output through a weighted average, which makes them faster and directly usable in control applications [22]. Inference proceeds in four steps: each crisp input is fuzzified across all linguistic terms; each rule’s firing strength is the product of its antecedent membership degrees (product t-norm); rules with non-zero firing strength are aggregated; and the output is defuzzified using: y=∑i=1Rwi⋅ci∑i=1Rwi,y= _i=1^Rw_i· c_i _i=1^Rw_i, (1) where wiw_i is the firing strength and cic_i is the consequent constant of rule i, summed over all R fired rules. This computation completes in sub-millisecond time, adding minimal overhead at the 5-second monitoring interval. IV Experimental Methodology Four experiments were conducted: (i) a multi-run variance experiment establishing reproducibility across fixed validator configurations, (i) a unified seven-phase closed-loop experiment in which the controller triggers validator activation in response to a workload that grows and then declines, (i) a comparative evaluation against three threshold-based controllers on the same unified workload, and (iv) an over-provisioned closed-loop experiment that exercises the Scale Down direction. IV-A Testbed and Workload The Substrate network was configured with 10 genesis authorities, an AURA slot duration of 6 seconds, and GRANDPA finality. The number of active validators was varied across 4, 7, and 10 for the multi-run experiment, and started at 4 for the closed-loop experiments. When fewer than the full 10 nodes are active, AURA’s round-robin assignment skips empty slots, increasing the effective block time. The expected effective block time for n active nodes is tslot×N/nt_slot× N/n, where N=10N=10 is the total authority count, giving 15.0 s, 8.57 s, and 6.0 s as nominal values for the three configurations. The fuzzy controller executes as a separate Python process that queries the blockchain via JSON-RPC every 5 seconds. Real smart water meter data was sourced from the Queensland Government open data portal [19], with daily Comma-Separated Values (CSV) files organised by meter count. Each file is SHA-256-hashed and the resulting 256-bit hash digest (H256, the Substrate hash type) is submitted on-chain through the custom pallet. Submission rate calibration established that the testbed sustains 75 extrinsics per second (ext/s) reliably. The unified workload therefore uses 75 ext/s as the heavy-load cap. IV-B Multi-run Variance Experiment For each of the three configurations, the experiment was repeated five times. Each repeat begins with a clean chain state: chain data is purged, AURA (Sr25519) and GRANDPA (Ed25519) keys are inserted into each active node’s keystore, and the network is launched. After stable block production is established, the load profile is applied while the controller samples the blockchain every 5 seconds for 420 seconds, recording all monitored variables at each interval. The five repeats support one-way Analysis of Variance (ANOVA) across configurations and pairwise Welch’s t-tests on the pooled samples. IV-C Unified Closed-loop Experiment TABLE I: Seven-Phase Unified Workload Phase Time (s) Load (ext/s) Conditions 1. Idle 0-120 1 Observing only 2. Ramp Up 120-300 5 → 75 Triggers at 180 s 3. Heavy 300-540 75 Sustained peak 4. Maintain High 540-660 75 Continued peak 5. Decline 660-840 75 → 2 Load decreases 6. Light 840-1080 2 Light load 7. Maintain Low 1080-1200 2 Low equilibrium The trigger logic is bidirectional by design, so the controller can both add and remove validators. Scale Up fires when the action value crosses 0.7 in a single sample and fewer than 10 validators are active; Scale Down fires when it falls below 0.3 and more than 4 validators are active. Whether a given direction is exercised depends on the workload: the cycle in Table I is designed to drive the network through under-provisioned, target, and potentially over-provisioned states. After any scaling action, a 30-second stabilisation window suppresses further decisions. Node activation is verified through the peer count reported by the bootnode; deactivation is performed by sending SIGTERM to the highest-numbered active validator. At every monitoring sample, the controller records the firing strength of each of the 27 rules in addition to the aggregated output. IV-D Over-provisioned Closed-loop Experiment To exercise the Scale Down direction, a second closed-loop experiment starts from an over-provisioned configuration of eight active validators under light load. The controller, membership functions, rule base, and decision thresholds are identical to those above; only the initial validator count and the workload differ. The workload has three phases: an idle observation phase (0–120 s, 1 ext/s) followed by sustained light load (120–900 s, 2 ext/s). The initial count is eight rather than ten because the calibrated Node Count Many term peaks at eight active validators, so starting at the chain ceiling of ten would place the input at the right foot of that term. An initial 60-second observation window precedes the first scaling decision, and the same 30-second stabilisation window applies after each action. IV-E Baselines and Statistical Analysis Three threshold-based controllers serve as baselines: Conservative (Scale Up if block time >12>12 s, 2.00×2.00× slot), Moderate (>10>10 s, 1.67×1.67×), and Aggressive (>8>8 s, 1.33×1.33×). All three use a Scale Down threshold of 7 s and a minimum of 4 active nodes. Each baseline runs the same seven-phase workload from identical starting conditions. Welch’s t-tests are computed on block time samples aggregated into three operational regimes: Scale Up (Phases 2-3), Maintain (Phases 4 and 7), and Scale Down (Phases 5-6); Cohen’s d reports effect sizes. Decision flips, counted as transitions between adjacent recommendation categories in consecutive samples, measure controller stability. V Results This section reports the experimental results across the three studies described in Section IV. V-A Multi-run Variance Across Configurations Table IV summarises the multi-run variance experiment. Each row reports the per-run mean and the within-run pooled standard deviation that captures the sample-level jitter. TABLE IV: Multi-run Variance Across Configurations (5 Repeats Each) Metric 4 active 7 active 10 active Block time mean (s) 13.92 7.78 6.00 Block time pooled std (s) 2.27 1.80 0.00 Block size mean (MB) 0.029 0.024 0.019 Efficiency mean (%) 44.07 54.82 50.00 Action value mean 0.639 0.435 0.500 Blocks produced (mean) 27.2 48.6 69.4 The three configurations produce distinct operational profiles. The 10-node configuration maintains a constant 6.00-second block time, as the full set of authority slots is filled and no production opportunities are missed. The 7-node configuration averages 7.78 s; the effective block time formula gives 6×10/7≈8.576× 10/7≈ 8.57 s, consistent with the measured value when adjacent filled slots partially offset the gaps. The 4-node configuration averages 13.92 s, close to 6×10/4=15.06× 10/4=15.0 s within the within-run jitter. The per-run means are deterministic given topology, because AURA’s round-robin assignment is fixed once the active set is decided, giving a between-run standard deviation of approximately zero. The meaningful variance lies within each run, as the rotation passes through filled and empty slot sequences; this is captured by the within-run pooled standard deviation. Because the per-run means are deterministic, the run-level statistics are highly concentrated: treating each run’s mean as a single observation, the between-run standard deviation is effectively zero (below 0.01 s) for all three configurations, so the run-level 95% confidence intervals on mean block time are narrower than ±0.01± 0.01 s. The configuration means (13.92, 7.78, and 6.00 s) are separated by far more than this spread, so the differences remain significant even when only the five run-level means per configuration are treated as independent observations. This addresses the concern that pooled time-series samples within a run may be autocorrelated. Statistical tests. One-way ANOVA across configurations on the pooled samples produces F=7229F=7229 for block time, F=1042F=1042 for efficiency, and F=2215F=2215 for action value, all with p<0.001p<0.001. Pairwise Welch’s t-tests on the within-run pooled samples confirm that all configuration pairs differ significantly (p<0.001p<0.001) on every measured metric. The 4-vs-10 comparison on block time produces t=71.37t=71.37, the largest magnitude in the analysis. V-B Unified Closed-loop Experiment Fig. 3 presents the time series of the 1200-second unified closed-loop experiment across all seven phases. Figure 3: Unified closed-loop experiment, 1200 s, seven phases. Top: block production time, with horizontal lines at 6 s (target) and 10 s (degraded). Middle: active node count, showing the two Scale Up events (4→ 5 at t=195t=195 s, 5→ 6 at t=240t=240 s). Bottom: action value with decision zone shading (green: Scale Down; yellow: Maintain; red: Scale Up). The controller triggers two Scale Up events during Phase 2. At t=195t=195 s the action value crosses 0.7 and the controller activates a fifth validator (peer discovery in 2.04 s); block time drops from 14.4 s to 10.2 s after the 30-second stabilisation window, within 1.8 s of the new effective slot target of 12.0 s. At t=240t=240 s a sixth validator is activated; block time drops from 13.0 s to 8.4 s, within 1.6 s of the 10.0 s target for six active nodes. After t=240t=240 s the controller holds the six-node configuration for the remaining 960 s. Block time settles at 8.4 s, slightly below the 10.0 s target, indicating that six validators are sufficient for the sustained load through Phases 3, 4, and 5. The controller produces no further scaling actions through Phases 6 or 7. The per-phase recommendation distributions are: 100% Maintain in Phases 1, 3, 4, 5, 6, and 7; 83.3% Maintain and 16.7% Scale Up in Phase 2. These distributions support H1a (two Scale Up events during the load increase when block time was elevated relative to the four-node target) and H1b (100% Maintain in both six-node equilibria, Phases 4 and 7). H1c (a Scale Down event under over-provisioning) was not triggered by this workload, which never drove the network above its target provisioning; it is demonstrated separately in Section V-D. H2 is supported by both scaling events: post-stabilisation block times approached the new effective slot target, reducing block time by 4.2 s and 4.6 s from pre-event values. Rule firing coverage: Six of the 27 rules produced firing strength of at least 0.1 in this experiment: R11, R14, R17, R20, R23, R26. R20 (Medium BT, Small BS, Moderate NC) dominates the Idle phase; R17 and R26 drive the Heavy and Maintain High phases as block size grows under the 75 ext/s load; R11 takes over when block size returns to baseline. The over-provisioned experiment (Section V-D) activates a seventh rule, R12, raising the combined coverage to seven rules across the two closed-loop experiments. The rules that remain unfired correspond to input combinations this architecture cannot produce: because block production time in an AURA chain is governed by the active validator count rather than by transaction volume, states such as High block time with Many active validators, or High block time with Small block size, do not co-occur in this testbed. These rules are retained for completeness and for deployments with different consensus or storage characteristics, consistent with the anchoring framework of Section I-B. V-C Comparison Against Threshold Baselines Table V compares the four controllers on the identical 1200-second unified workload. Each controller starts at four active validators with the same load profile. TABLE V: Per-controller Comparison Metrics (Identical Unified Workload) Controller Up Down Flips Final BT (s) Final Eff (%) TS Fuzzy 2 0 4 8.4 67.9 Conservative 3 1 4 12.0 40.0 Moderate 18 14 29 7.9 81.0 Aggressive 17 12 24 11.0 50.0 The four controllers differ markedly. The TS controller issues 2 scaling actions and 4 decision flips over 1200 s. The Conservative produces 4 flips but settles at a final efficiency of only 40%. Moderate and Aggressive are highly reactive, producing 24-29 flips across 17-18 Scale Up and 12-14 Scale Down actions. Fig. 4 visualises the contrast. The TS column shows a smooth action value progression that remains predominantly in the Maintain zone. Moderate and Aggressive show pronounced square-wave oscillation as block time crosses and re-crosses the fixed thresholds; Conservative oscillates less but at a much higher block time band. Figure 4: Four-controller comparison under the identical unified workload. Top row: block production time with reference lines at 6 s (target) and 10 s (degraded). Bottom row: action value with decision zone shading. The TS controller produces a smooth progression; the threshold controllers oscillate around their fixed cut-offs. Statistical comparison: Table VI reports pairwise Welch’s t-tests on block time aggregated into three operational regimes. Against Conservative, the TS controller produces significantly lower block times across all three regimes, with large effect sizes (d=−2.10d=-2.10 and −2.11-2.11 in Maintain and Scale Down). Against Moderate, the TS controller is slightly slower in the Scale Up regime (the threshold scales earlier and more often) but differences in Maintain and Scale Down are small and not significant. Against Aggressive, a similar pattern holds with a medium effect in Maintain (d=−0.73d=-0.73). The decision flip counts in Table V are the strongest discriminator: 4 flips for TS against 24 and 29 for the reactive thresholds. This is the core stability-reactivity trade-off: more reactive controllers occasionally achieve lower block times at the cost of substantially more scaling churn, while the TS controller’s smoother decision surface produces a quiet operating regime with comparable end-state performance. TABLE VI: Welch’s t-tests on Block Time, TS vs Threshold (by Regime) TS vs Regime t p d Conservative Scale Up −3.78-3.78 <0.001<0.001 −0.58-0.58 Conservative Maintain −10.28-10.28 <0.001<0.001 −2.10-2.10 Conservative Scale Down −13.67-13.67 <0.001<0.001 −2.11-2.11 Moderate Scale Up 2.56 -2.56 0.0120.012 0.39 -0.39 Moderate Maintain −1.79-1.79 0.0770.077 −0.36-0.36 Moderate Scale Down −1.84-1.84 0.0680.068 −0.28-0.28 Aggressive Scale Up 2.56 -2.56 0.0120.012 0.39 -0.39 Aggressive Maintain −3.11-3.11 0.0030.003 −0.73-0.73 Aggressive Scale Down −1.84-1.84 0.0680.068 −0.28-0.28 d is Cohen’s effect size. Negative d: TS block time lower than baseline. V-D Scale Down Under Over-Provisioning The unified workload exercised Scale Up and Maintain. The over-provisioned experiment (Section IV-D) exercises the Scale Down direction. Fig. 5 presents the 900-second time series, starting from eight active validators under light load. At eight active validators the action value held at 0.250, in the Scale Down region, with block time oscillating between 6.0 and 8.4 s as AURA rotates through filled and empty slots. The controller deactivated one validator at t=60t=60 s (eight to seven active) and a second at t=105t=105 s (seven to six active), both during the idle phase, each followed by the 30-second stabilisation window. After convergence, block time at six active validators averaged 8.4 s (oscillating between 6.0 and 10.8 s) and the action value rose to a mean of 0.46, within the Maintain band. The controller held the six-validator configuration for the remainder of the run, with no further scaling. The recommendation distribution was 91.7% Scale Down during the idle phase and 100% Maintain thereafter. This confirms convergence from above: the over-provisioned eight-validator network was reduced to the same six-validator equilibrium reached from below in the unified experiment, at the same mean block time of 8.4 s. The over-provisioning rule R12 (Medium BT, Small BS, Many NC) fired only in this experiment, dominating the idle phase before convergence; at equilibrium R11 again dominates. Across both closed-loop experiments the controller exercised both scaling directions, each converging to a stable equilibrium. Figure 5: Over-provisioned closed-loop experiment, 900 s, starting from eight active validators under light load. Top: block production time, with reference lines at 6 s (target) and 10 s (degraded). Middle: active node count, showing two Scale Down events (8→ 7 at t=60t=60 s, 7→ 6 at t=105t=105 s). Bottom: action value with decision zone shading (green: Scale Down; yellow: Maintain; red: Scale Up). The controller converges to the same six-validator equilibrium reached from below in Fig. 3. VI Discussion VI-A Stability versus Reactivity The most prominent pattern is the trade-off between scaling stability and reactivity. The TS controller produces 4 decision flips against 24 to 29 for the Moderate and Aggressive variants, an order-of-magnitude difference. The threshold logic produces this oscillation directly: a scaling decision changes category each time block time crosses the fixed cut-off. Because block time naturally fluctuates around the effective slot duration as AURA rotates through validators, the threshold controllers spend much of the experiment in flux. The TS controller avoids this through degrees of membership: a block time of 9.6 s holds partial membership in both Medium and High, so firing strengths combine smoothly and the output changes gradually with the input rather than discontinuously. For production deployments where each scaling action involves keystore configuration, peer discovery, and chain synchronisation, two actions are far preferable to seventeen. Notably, the proposed controller already incorporates a cooldown policy in the form of the 30-second stabilisation window, so the baselines and the TS controller are held to the same stabilisation constraint; the difference in stability therefore stems from fuzzy inference rather than from cooldown alone. VI-B Generalisability and Determinism The empirical recalibration framework in Section I-B addresses a practical concern with fuzzy controllers, namely that MF parameters are often tied to specific deployment characteristics. The refinement shifts the BT High triangle peak from 20 s (the worst-case prediction from the effective slot formula) to 14 s (the actual observed worst case), and moves the NC Many peak from 10 (the chain authority ceiling) to 8 (the realistic “fully scaled” point for a controller starting at four active validators). The worked examples in Table I show that the same anchoring rule transfers across chains with substantially different slot durations. The 27 rules and their consequents transfer without modification. VII Conclusion This paper presented a closed-loop dynamic validator node scaling system for private Substrate blockchains, with a TS fuzzy inference controller that monitors live blockchain parameters and triggers validator activation through verified peer discovery. The MFs are anchored to the empirically observed operating range, with a generalisable anchoring rule and four worked examples covering different deployment configurations. The experimental evaluation tested three hypotheses on a 10-authority Substrate testbed with real smart water meter data. The controller produced statistically distinct operational profiles across configurations of 4, 7, and 10 active validators (one-way ANOVA F=7229F=7229 on block time, p<0.001p<0.001). In a unified seven-phase 1200-second closed-loop experiment, the controller triggered two Scale Up events as load increased, reaching a six-validator equilibrium that held through both the sustained peak load and the return to baseline. A separate over-provisioned experiment exercised the Scale Down direction, converging from eight validators to the same six-validator equilibrium. Against three threshold baselines, the TS controller produced 4 decision flips compared with 24 to 29 for the more reactive thresholds while maintaining comparable block times, with Welch’s t-tests confirming large effect sizes (|d||d| up to 2.112.11). Future work will develop an evolving variant that adapts MF parameters online, compare against hysteresis and PID baselines, and add complementary fuzzy subsystems for storage configuration and archival management. Acknowledgment A use of generative AI assistant (Anthropic Claude) for language editing. All technical content, including the system design, experiments, analyses, and conclusions, is the authors’ own, and the authors reviewed and verified all text in the paper. References [1] M. S. Ali, K. Dolui, and F. Antonelli (2017) IoT data privacy via blockchains and IPFS. In Proceedings of the Seventh International Conference on the Internet of Things, IoT ’17, New York, NY, USA. External Links: Document Cited by: §I-C. [2] Saif. E. A. Alnawayseh, M. H. G. Muhammad, Z. Hassan, M. Fatima, M. S. Aslam, A. Ibrahim, and K. Ateeq (2023) Resource provisioning in cloud computing using fuzzy logic control system: an adaptive approach. In 2023 International Conference on Business Analytics for Technology and Security (ICBATS), p. 1–9. External Links: Document Cited by: §I-B. [3] L. Alouache, T. Sylla, L. Mendiboure, and H. Aniss (2022) A fuzzy approach for load balancing in blockchain-based software defined vehicular networks. In 2022 18th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), p. 235–242. External Links: Document Cited by: §I-B. [4] V. Buterin (2021-04) Why sharding is great: demystifying the technical properties. Note: https://vitalik.eth.limo/general/2021/04/07/sharding.htmlAccessed: 2026-03-11 Cited by: §I-A. [5] H. Dai, Z. Zheng, and Y. Zhang (2019) Blockchain for Internet of Things: a survey. IEEE Internet of Things Journal 6 (5), p. 8076–8094. External Links: Document Cited by: §I, §I-C. [6] X. He, Y. Zhang, and X. Wang (2022) A scalable nested blockchain framework with dynamic node selection approach for IoT. In 2022 IEEE International Performance, Computing, and Communications Conference (IPCCC), p. 108–113. External Links: Document Cited by: §I-A. [7] S. Jabbar, Z. U. Abideen, S. Khalid, A. Ahmad, U. Raza, and S. Akram (2023) Enhancing computational scalability in blockchain by leveraging improvement in consensus algorithm. Frontiers in Computer Science 5, p. 1304590. External Links: Document Cited by: §I, §I-A. [8] A. Kaur and A. Kaur (2012) Comparison of Mamdani-type and Sugeno-type fuzzy inference systems for air conditioning system. International Journal of Soft Computing and Engineering 2 (2), p. 323–325. Cited by: §I-B, §I-E. [9] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford (2018) OmniLedger: a secure, scale-out, decentralized ledger via sharding. In 2018 IEEE Symposium on Security and Privacy (SP), p. 583–598. External Links: Document Cited by: §I-A. [10] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena (2016) A secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, p. 17–30. External Links: Document Cited by: §I-A. [11] A. A. Maftei, A. Lavric, A. I. Petrariu, and V. Popa (2023) Massive data storage solution for IoT devices using blockchain technologies. Sensors 23 (3), p. 1570. External Links: Document Cited by: §I-C. [12] S. Nakamoto (2008) Bitcoin: a peer-to-peer electronic cash system. Note: Available: https://bitcoin.org/bitcoin.pdf Cited by: §I. [13] T. Nododile and C. N. Nyirenda (2024) Advancing blockchain-enabled InterPlanetary File System with Substrate for distributed data storage. In 2024 International Conference on Emerging Trends in Networks and Computer Communications (ETNCC), p. 1–8. External Links: Document Cited by: §I, §I-C. [14] T. Nododile and C. Nyirenda (2023) A blockchain-based secure data collection mechanism for smart water meters. In 2023 IST-Africa Conference (IST-Africa), p. 1–8. External Links: Document Cited by: §I, §I-C. [15] T. Nododile and C. Nyirenda (2025) A hybrid blockchain-ipfs solution for secure and scalable data collection and storage in smart water meters. In 2025 IST-Africa Conference (IST-Africa), Vol. , p. 1–9. External Links: Document Cited by: §I, §I-C. [16] C. N. Nyirenda, D. S. Dawoud, F. Dong, M. Negnevitsky, and K. Hirota (2011) A fuzzy multiobjective particle swarm optimized ts fuzzy logic congestion controller for wireless local area networks. Journal of Advanced Computational Intelligence and Intelligent Informatics 15 (1), p. 41–54. Cited by: §I-E. [17] C. Nyirenda and D. Dawoud (2008) Self-organization in a particle swarm optimized fuzzy logic congestion detection mechanism for ip networks. Scientia Iranica 15 (6). Cited by: §I-E. [18] A. O. Omondi, E. O. Obare, and S. Oonge (2025-Jun.) Adaptive fuzzy logic risk-based access control model for smart contract execution. International Journal of Progressive Research in Science and Engineering 6, p. 56–75. Cited by: §I-B. [19] Queensland Government (2022) Digital water meter data. Note: https://w.data.qld.gov.au/dataset/digital-water-meter-dataset-explanationAccessed: 2026-03-04 Cited by: §IV-A. [20] A. Reyna, C. Martín, J. Chen, E. Soler, and M. Díaz (2018) On blockchain and its integration with IoT: challenges and opportunities. Future Generation Computer Systems 88, p. 173–190. External Links: Document Cited by: §I, §I-C. [21] S. Suryavansh, A. Benna, C. Guest, and S. Chaterji (2021-Nov.) A data-driven approach to increasing the lifetime of IoT sensor nodes. Scientific Reports 11 (1), p. 22459. External Links: Document, ISSN 20452322 Cited by: §I. [22] T. Takagi and M. Sugeno (1985) Fuzzy identification of systems and its applications to modeling and control. IEEE Transactions on Systems, Man, and Cybernetics SMC-15 (1), p. 116–132. External Links: Document Cited by: §I, §I-B, §I-E. [23] G. Wood and Parity Technologies (2024) Substrate developer documentation. Note: https://docs.substrate.io/Accessed: 2026-03-9 Cited by: §I, §I-A. [24] J. Xie, H. Tang, T. Huang, F. R. Yu, R. Xie, J. Liu, and Y. Liu (2019) A survey of blockchain technology applied to smart cities: research issues and challenges. IEEE Communications Surveys & Tutorials 21 (3), p. 2794–2830. External Links: Document Cited by: §I-A. [25] L. A. Zadeh (1965) Fuzzy sets. Information and Control 8 (3), p. 338–353. External Links: Document Cited by: §I, §I-B. [26] Z. Zhang, Y. Shi, Z. Zhang, and W. Yan (2019) New results on sliding-mode control for Takagi–Sugeno fuzzy multiagent systems. IEEE Transactions on Cybernetics 49 (5), p. 1592–1604. External Links: Document Cited by: §I, §I-B. [27] J. Zhao and B. K. Bose (2002) Evaluation of membership functions for fuzzy logic controlled induction motor drive. In IEEE 2002 28th Annual Conference of the Industrial Electronics Society. IECON 02, Vol. 1, p. 229–234. External Links: Document Cited by: §I-B. [28] Q. Zhou, H. Huang, Z. Zheng, and J. Bian (2020) Solutions to scalability of blockchain: a survey. IEEE Access 8, p. 16440–16455. External Links: Document Cited by: §I-A.