Closed-Loop Dynamic Validator Node Scaling in Private Substrate Blockchains Using Takagi-Sugeno Fuzzy Inference Thandile Nododile, Ayinde M. Usman, Clement N. Nyirenda
arXiv:2607.07901v1 [cs.CR] 8 Jul 2026
Department of Computer Science University of the Western Cape, South Africa 0009-0000-1386-2425, 0000-0003-1926-3508, 0000-0002-4181-0478 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. Index Terms—Adaptive control, blockchain, fuzzy logic, IoT, Substrate, Takagi-Sugeno, validator node scaling
I. I NTRODUCTION Blockchain technology provides a distributed, tamperresistant ledger architecture suitable for applications requiring data integrity and auditability [1]. 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 [2], [3]. 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 [4]. 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 [5]. 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 [6]. 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 [7] addresses this through degrees of membership, allowing multiple inputs to contribute proportionally to a decision. The Takagi-Sugeno (TS) fuzzy inference system [8] 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 [9]. Prior work has established blockchain architectures for IoT data integrity [10], integrated Substrate with the InterPlanetary File System (IPFS) for off-chain storage [11], and demonstrated hybrid blockchain-IPFS solutions on smart water meter data [12]. 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
979-8-3195-0703-7/26/$31.00© 2026 IEEE
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; (ii) an empirical recalibration of fuzzy membership functions with a generalisable anchoring rule and worked examples; (iii) 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. II. R ELATED W ORK A. Blockchain Scalability and Node Management Blockchain scalability is a well-known challenge [13], [14], with the tension between decentralisation, security, and throughput [15] 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) [4]. These mechanisms operate on static, pre-configured rules; when transaction rates change, fixed validator configurations cannot adapt [6]. Protocol-level approaches such as sharding [16], [17] partition the network to process transactions in parallel but introduce cross-shard coordination complexity. He et al. [18] 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. B. Fuzzy Logic for Distributed Resource Management Fuzzy set theory [7] extends classical set theory by allowing partial membership, providing a mathematical framework for handling uncertainty in decision-making. The TS fuzzy inference system [8] uses crisp mathematical functions as
rule consequents, which approximates nonlinear systems efficiently. Kaur and Kaur [19] found Sugeno inference more computationally efficient than Mamdani for real-time control, and Zhao and Bose [20] showed that triangular membership functions balance simplicity with control accuracy. TS models have been applied to networked control systems with communication constraints [9]. Fuzzy logic has been applied to resource allocation in cloud and edge contexts [21]. Closer to blockchain, Alouache et al. [22] applied fuzzy logic to real-time reconfiguration in blockchain-based vehicular networks, and Omondi et al. [23] 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. C. Blockchain-IoT Data Storage The growth of IoT deployments generates large volumes of sensor data requiring secure, distributed storage [3]. Blockchain offers data integrity through its append-only structure but faces storage and throughput limitations when processing continuous streams [2]. Combining blockchain with IPFS addresses storage constraints by keeping large data objects offchain while recording content hashes on-chain [24], with applications across healthcare, supply chain, and industrial IoT [25]. A line of prior work has developed blockchain architectures for IoT data integrity, including a Substrate-based mechanism for smart water meter data [10], Substrate-IPFS integration for distributed storage [11], and a hybrid blockchain-IPFS solution [12]. 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. III. S YSTEM D ESIGN 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 III-A, contribution i) and the empirical recalibration of the membership functions with a generalisable anchoring rule (Section III-B, contribution ii). Algorithm 1 summarises the closed-loop procedure. 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
IoT Data Layer CSV files → SHA256 → H256 extrinsics
Substrate Blockchain 10 nodes, AURA + GRANDPA, custom pallet block time, size, peers
JSON-RPC Bridge chain_getBlock, system_health 3 crisp inputs
TS Fuzzy Controller 27 rules → Efficiency + Action
Scale Down / Maintain / Scale Up Fig. 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.
Algorithm 1 Closed-Loop Validator Node Scaling 1: n ← initial active validators; cooldown ← 0 2: loop 3: wait 5 s; read block time bt, block size bs, node count n 4: fuzzify (bt, bs, n) over all linguistic terms 5: compute firing strengths wi (product t-norm) for the 27 rules P P 6: a ← ( i wi ci ) / ( i wi ) {action value} 7: if cooldown > 0 then 8: cooldown ← cooldown − 5 {suppress decisions} 9: else if a ≥ 0.7 and n < 10 then 10: activate validator; verify peer discovery 11: n ← n + 1; cooldown ← 30 {Scale Up} 12: else if a < 0.3 and n > 4 then 13: deactivate highest-numbered validator (SIGTERM) 14: n ← n − 1; cooldown ← 30 {Scale Down} 15: else 16: maintain configuration {Maintain} 17: end if 18: end loop TABLE I C ALIBRATED M EMBERSHIP F UNCTION PARAMETERS
GRANDPA for deterministic finalisation. The third layer is a JavaScript Object Notation Remote Procedure Call (JSONRPC) 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. The blockchain stores IoT data through a custom pallet that accepts SHA256 hashes of data files via a storeDataHash(H256) extrinsic. Raw data remains offchain; 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. 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] representing the left foot, peak, and right foot. Fig. 2 shows the calibrated MFs used in this work. 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,
Variable
Term
Parameters [a, b, c]
Block Time (s)
Low Medium High
[0, 0, 6] [4, 9, 14] [10, 14, 18]
Block Size (MB)
Small Medium Large
[0, 0, 0.005] [0.002, 0.015, 0.030] [0.020, 0.040, 0.060]
Node Count
Few Moderate Many
[1, 1, 4] [3, 5, 7] [6, 8, 10]
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 hashstorage 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 II shows worked examples of how the same anchoring rule transfers to chains with different slot durations. 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
Low
Medium
High
μ(x)
1.00 0.75 0.50 0.25 0.00 0
5
10
15
20
25
Block Time (s)
Small
Medium
Large
μ(x)
1.00 0.75 0.50
E. TS Fuzzy Inference
0.25
The controller employs a zero-order TS fuzzy inference system [26]. Unlike Mamdani systems [19], [27], 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 [8]. 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: PR i=1 wi · ci , (1) y= P R i=1 wi
0.00 0.00
0.01
0.02
0.03
0.04
0.05
0.06
0.07
Block Size (MB)
Few
Moderate
Many
6
8
10
1.00
μ(x)
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.
0.75 0.50 0.25 0.00 0
2
4
Node Count
Fig. 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. TABLE II W ORKED E XAMPLES : A NCHORING RULE ACROSS D EPLOYMENT C ONFIGURATIONS
where wi is the firing strength and ci 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. E XPERIMENTAL M ETHODOLOGY
Deployment
Slot
Active/Auth.
Effective Slot
This work (4-of-10 baseline) This work (full topology) Fast Substrate (3 s slot) Slow Substrate (12 s slot)
6s 6s 3s 12 s
4/10 10/10 -
15.0 s 6.0 s 3.0 s 12.0 s
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). D. Rule Base The rule base consists of 27 rules covering every combination of three input variables with three terms each (3×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,
Four experiments were conducted: (i) a multi-run variance experiment establishing reproducibility across fixed validator configurations, (ii) a unified seven-phase closed-loop experiment in which the controller triggers validator activation in response to a workload that grows and then declines, (iii) a comparative evaluation against three threshold-based controllers on the same unified workload, and (iv) an overprovisioned closed-loop experiment that exercises the Scale Down direction. 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/n, where N = 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.
TABLE III S EVEN -P HASE U NIFIED W ORKLOAD Phase
Time (s)
Load (ext/s)
Conditions
1. Idle 2. Ramp Up 3. Heavy 4. Maintain High 5. Decline 6. Light 7. Maintain Low
0-120 120-300 300-540 540-660 660-840 840-1080 1080-1200
1 5 → 75 75 75 75 → 2 2 2
Observing only Triggers at 180 s Sustained peak Continued peak Load decreases Light load Low equilibrium
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. E. Baselines and Statistical Analysis
Real smart water meter data was sourced from the Queensland Government open data portal [28], with daily CommaSeparated 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. 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. C. Unified Closed-loop Experiment 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 III 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. D. Over-provisioned Closed-loop Experiment To exercise the Scale Down direction, a second closedloop 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
Three threshold-based controllers serve as baselines: Conservative (Scale Up if block time > 12 s, 2.00× slot), Moderate (> 10 s, 1.67×), and Aggressive (> 8 s, 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. R ESULTS This section reports the experimental results across the three studies described in Section IV. 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 M ULTI - RUN VARIANCE ACROSS C ONFIGURATIONS (5 R EPEATS E ACH ) Metric
4 active
7 active
10 active
Block time mean (s) Block time pooled std (s) Block size mean (MB) Efficiency mean (%) Action value mean Blocks produced (mean)
13.92 2.27 0.029 44.07 0.639 27.2
7.78 1.80 0.024 54.82 0.435 48.6
6.00 0.00 0.019 50.00 0.500 69.4
The three configurations produce distinct operational profiles. The 10-node configuration maintains a constant 6.00second 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.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.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 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 timeseries samples within a run may be autocorrelated. Statistical tests. One-way ANOVA across configurations on the pooled samples produces F = 7229 for block time, F = 1042 for efficiency, and F = 2215 for action value, all with p < 0.001. Pairwise Welch’s t-tests on the withinrun pooled samples confirm that all configuration pairs differ significantly (p < 0.001) on every measured metric. The 4-vs10 comparison on block time produces t = 71.37, the largest magnitude in the analysis. B. Unified Closed-loop Experiment Fig. 3 presents the time series of the 1200-second unified closed-loop experiment across all seven phases. The controller triggers two Scale Up events during Phase 2. At t = 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 = 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 = 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 sixnode 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
TABLE V P ER - CONTROLLER C OMPARISON M ETRICS (I DENTICAL U NIFIED W ORKLOAD ) Controller
Up
Down
Flips
Final BT (s)
Final Eff (%)
TS Fuzzy Conservative Moderate Aggressive
2 3 18 17
0 1 14 12
4 4 29 24
8.4 12.0 7.9 11.0
67.9 40.0 81.0 50.0
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 III-B. C. Comparison Against Threshold Baselines Table V compares the four controllers on the identical 1200second unified workload. Each controller starts at four active validators with the same load profile. 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. 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.10 and −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.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
Idle
Block time (s)
20
Ramp Up
Heavy
Maintain Hi
Decline
Light
15 10 5
Target (6 s)
0
Active nodes
Maintain Lo
10 9 8 7 6 5 4
Degraded (10 s)
+6 +5
1.0
Action value
0.8 0.6 0.4 0.2 0.0
0
200
400
600
800
Time (s)
1000
1200
Fig. 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 = 195 s, 5→6 at t = 240 s). Bottom: action value with decision zone shading (green: Scale Down; yellow: Maintain; red: Scale Up). Target (6 s)
Action value
Block time (s)
TS Fuzzy
Conservative
Degraded (10 s)
Moderate
Aggressive
20
20
20
20
15
15
15
15
10
10
10
10
5
5
5
5
0 1.0
0 1.0
0 1.0
0 1.0
0.8
0.8
0.8
0.8
0.6
0.6
0.6
0.6
0.4
0.4
0.4
0.4
0.2
0.2
0.2
0.2
0.0
0.0
0.0
0
200
400
600
Time (s)
800 1000 1200
0
200
400
600
Time (s)
800 1000 1200
0
200
400
600
Time (s)
800 1000 1200
0.0
0
200
400
600
Time (s)
800 1000 1200
Fig. 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.
TS controller’s smoother decision surface produces a quiet operating regime with comparable end-state performance. 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 = 60 s (eight to seven active) and a second at t = 105 s (seven to six active), both during the idle phase, each followed by the 30second 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-
TABLE VI W ELCH ’ S T- TESTS ON B LOCK T IME , TS VS T HRESHOLD ( BY R EGIME ) t
p
d
TS vs
Regime
Conservative Conservative Conservative
Scale Up Maintain Scale Down
−3.78 < 0.001 −0.58 −10.28 < 0.001 −2.10 −13.67 < 0.001 −2.11
Moderate Moderate Moderate
Scale Up Maintain Scale Down
2.56 −1.79 −1.84
0.012 0.077 0.068
0.39 −0.36 −0.28
Aggressive Scale Up 2.56 0.012 0.39 Aggressive Maintain −3.11 0.003 −0.73 Aggressive Scale Down −1.84 0.068 −0.28 d is Cohen’s effect size. Negative d: TS block time lower than baseline. Target (6 s)
Block time (s)
11
Idle
Degraded (10 s)
Scale Down
Light — scale down
Light — converge
10 9
B. Generalisability and Determinism
8 7
Active validators
6
10
-7
9
-6
8 7 6 5 4
1.0
Action value
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.
0.8 0.6 0.4 0.2 0.0 0
100
200
300
400
500
600
700
800
900
Time (s)
Fig. 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 = 60 s, 7→6 at t = 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.
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. VI. D ISCUSSION 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.
The empirical recalibration framework in Section III-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 II show that the same anchoring rule transfers across chains with substantially different slot durations. The 27 rules and their consequents transfer without modification. VII. C ONCLUSION 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 = 7229 on block time, p < 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 sixvalidator 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| up to 2.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. R EFERENCES [1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Available: https://bitcoin.org/bitcoin.pdf, 2008. [2] H.-N. Dai, Z. Zheng, and Y. Zhang, “Blockchain for Internet of Things: A survey,” IEEE Internet of Things Journal, vol. 6, no. 5, pp. 8076–8094, 2019. [3] A. Reyna, C. Martı́n, J. Chen, E. Soler, and M. Dı́az, “On blockchain and its integration with IoT: Challenges and opportunities,” Future Generation Computer Systems, vol. 88, pp. 173–190, 2018. [4] G. Wood and Parity Technologies, “Substrate developer documentation,” https://docs.substrate.io/, 2024, accessed: 2026-03-9. [5] S. Suryavansh, A. Benna, C. Guest, and S. Chaterji, “A data-driven approach to increasing the lifetime of IoT sensor nodes,” Scientific Reports, vol. 11, no. 1, p. 22459, Nov. 2021. [6] S. Jabbar, Z. U. Abideen, S. Khalid, A. Ahmad, U. Raza, and S. Akram, “Enhancing computational scalability in blockchain by leveraging improvement in consensus algorithm,” Frontiers in Computer Science, vol. 5, p. 1304590, 2023. [7] L. A. Zadeh, “Fuzzy sets,” Information and Control, vol. 8, no. 3, pp. 338–353, 1965. [8] T. Takagi and M. Sugeno, “Fuzzy identification of systems and its applications to modeling and control,” IEEE Transactions on Systems, Man, and Cybernetics, vol. SMC-15, no. 1, pp. 116–132, 1985. [9] Z. Zhang, Y. Shi, Z. Zhang, and W. Yan, “New results on slidingmode control for Takagi–Sugeno fuzzy multiagent systems,” IEEE Transactions on Cybernetics, vol. 49, no. 5, pp. 1592–1604, 2019. [10] T. Nododile and C. Nyirenda, “A blockchain-based secure data collection mechanism for smart water meters,” in 2023 IST-Africa Conference (ISTAfrica). IEEE, 2023, pp. 1–8. [11] T. Nododile and C. N. Nyirenda, “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), 2024, pp. 1–8. [12] T. Nododile and C. Nyirenda, “A hybrid blockchain-ipfs solution for secure and scalable data collection and storage in smart water meters,” in 2025 IST-Africa Conference (IST-Africa), 2025, pp. 1–9. [13] Q. Zhou, H. Huang, Z. Zheng, and J. Bian, “Solutions to scalability of blockchain: A survey,” IEEE Access, vol. 8, pp. 16 440–16 455, 2020. [14] J. Xie, H. Tang, T. Huang, F. R. Yu, R. Xie, J. Liu, and Y. Liu, “A survey of blockchain technology applied to smart cities: Research issues and challenges,” IEEE Communications Surveys & Tutorials, vol. 21, no. 3, pp. 2794–2830, 2019. [15] V. Buterin, “Why sharding is great: Demystifying the technical properties,” https://vitalik.eth.limo/general/2021/04/07/sharding.html, Apr. 2021, accessed: 2026-03-11. [16] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena, “A secure sharding protocol for open blockchains,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 17–30. [17] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford, “OmniLedger: A secure, scale-out, decentralized ledger via sharding,” in 2018 IEEE Symposium on Security and Privacy (SP), 2018, pp. 583–598. [18] X. He, Y. Zhang, and X. Wang, “A scalable nested blockchain framework with dynamic node selection approach for IoT,” in 2022 IEEE International Performance, Computing, and Communications Conference (IPCCC), 2022, pp. 108–113. [19] A. Kaur and A. Kaur, “Comparison of Mamdani-type and Sugenotype fuzzy inference systems for air conditioning system,” International Journal of Soft Computing and Engineering, vol. 2, no. 2, pp. 323–325, 2012.
[20] J. Zhao and B. K. Bose, “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, 2002, pp. 229–234. [21] S. E. A. Alnawayseh, M. H. G. Muhammad, Z. Hassan, M. Fatima, M. S. Aslam, A. Ibrahim, and K. Ateeq, “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), 2023, pp. 1–9. [22] L. Alouache, T. Sylla, L. Mendiboure, and H. Aniss, “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), 2022, pp. 235– 242. [23] A. O. Omondi, E. O. Obare, and S. Oonge, “Adaptive fuzzy logic riskbased access control model for smart contract execution,” International Journal of Progressive Research in Science and Engineering, vol. 6, pp. 56–75, Jun. 2025. [24] M. S. Ali, K. Dolui, and F. Antonelli, “IoT data privacy via blockchains and IPFS,” in Proceedings of the Seventh International Conference on the Internet of Things, ser. IoT ’17. New York, NY, USA: Association for Computing Machinery, 2017. [25] A. A. Maftei, A. Lavric, A. I. Petrariu, and V. Popa, “Massive data storage solution for IoT devices using blockchain technologies,” Sensors, vol. 23, no. 3, p. 1570, 2023. [26] C. N. Nyirenda, D. S. Dawoud, F. Dong, M. Negnevitsky, and K. Hirota, “A fuzzy multiobjective particle swarm optimized ts fuzzy logic congestion controller for wireless local area networks,” Journal of Advanced Computational Intelligence and Intelligent Informatics, vol. 15, no. 1, pp. 41–54, 2011. [27] C. Nyirenda and D. Dawoud, “Self-organization in a particle swarm optimized fuzzy logic congestion detection mechanism for ip networks,” Scientia Iranica, vol. 15, no. 6, 2008. [28] Queensland Government, “Digital water meter data,” https://www.data. qld.gov.au/dataset/digital-water-meter-dataset-explanation, 2022, accessed: 2026-03-04.