Bayesian-driven autonomous defense adaptive consensus optimisation for blockchain networks

Abstract

Blockchain networks have revolutionized decentralized applications but remain vulnerable to evolving security threats due to their reliance on static consensus mechanisms that cannot adapt to changing threat landscapes. This paper addresses this critical security gap by proposing Autonomous Defense-Adaptive Consensus Optimisation for Blockchain Networks (ADACON), an original framework for the dynamic adjustment of consensus mechanisms based on Bayesian threat detection. The research investigates how real-time adaptation between multiple consensus protocols can enhance blockchain resilience while maintaining performance. The approach integrates a Bayesian Threat Detector, Consensus Adapter, and Network State monitor in a modular architecture that continuously assesses network conditions and switches between five consensus mechanisms (PoW, PoS, PBFT, PoA, DPoS) as threats emerge. The framework was evaluated through comprehensive simulations involving 1,000 nodes, testing response to six distinct attack vectors, including Sybil, DoS, Byzantine, Eclipse, Majority, and Routing attacks. Results demonstrate that ADACON effectively identifies and responds to varied attacks with a latency of 29.7 ms and throughput of 833 TPS). Statistical validation across five independent simulation runs (seeds 5–9) confirmed framework reliability with consistent performance metrics (CV < 7.1% for latency, 5.4% for throughput). Delegated Proof of Stake emerged as the most frequently selected mechanism (23.2%) due to its balanced performance across multiple security dimensions. Significantly, the system exhibited greater adaptability and attack coverage than existing hybrid approaches. The previous high switching frequency was reduced by using hysteresis, i.e., by providing dwell time and an improved threshold that avoids unnecessary switching. The study concludes that dynamic consensus adaptation offers substantial security advantages for blockchain networks, particularly in high-security environments like financial systems and critical infrastructure. However, further research must focus on optimizing switching frequency and developing secure transition protocols to maximize effectiveness. ADACON represents an incremental extension tested toward more resilient blockchain systems that can autonomously respond to emerging threats while balancing security, performance, and resource utilization.

Introduction

Blockchain consensus protocols provide the foundational trust layer for decentralized systems, enabling distributed agreement without centralized authority. Despite significant advances, contemporary protocols remain fundamentally constrained by their inability to adapt dynamically to evolving threat landscapes. Static consensus mechanisms such as Proof-of-Work (PoW) and Proof-of-Stake (PoS) operate with fixed parameters that cannot respond to real-time adversarial conditions. Hybrid approaches (e.g., PoW + PoS, PoW + BFT) represent progress in multi-protocol integration but rely on predetermined switching logic or governance-driven reconfiguration, lacking the temporal granularity required for immediate threat mitigation. Recent systems demonstrate incremental progress toward adaptability. Decred’s hybrid PoW + PoS¹ established dual-protocol viability, HyFlexChain² introduced dynamic PoW-BFT selection based on network conditions, and Cosmos enabled governance-driven protocol upgrades. DL-DPoS³ refined adaptability through reputation-based node selection. However, these architectures share critical limitations: (1) architectural rigidity typically supporting only two fixed mechanisms, (2) latency in threat response relying on manual governance, introducing delays of hours or days; and (3) absence of integrated threat intelligence lacking real-time attack detection systems.

These gaps become critical as blockchain networks face sophisticated adversaries deploying Sybil infiltration, distributed denial-of-service, Byzantine behavior, Eclipse isolation, majority attacks, and routing manipulation. Modern attack vectors exploit static consensus protocols during transition periods or governance vulnerabilities, representing significant security gaps in critical infrastructure supporting financial systems, supply chains, and governmental services. This research introduces ADACON (Autonomous Defense-Adaptive Consensus Optimization), a novel framework integrating Bayesian probabilistic threat inference with dynamic consensus switching across five mechanisms (PoW, PoS, PBFT, PoA, DPoS). ADACON autonomously monitors network telemetry, computes attack probabilities, and reconfigures protocols in real time achieving a paradigmatic shift from passive, fixed defense to active consensus adaptation that continuously optimizes security, performance, and efficiency.

Research objectives

This study pursues three primary objectives:

• 1. Real-time threat detection: Develop a Bayesian inference engine monitoring network metrics (latency variance, block propagation delays, validation failures, partitioning indicators) to compute posterior attack probabilities with millisecond-scale latency.

• 2. Adaptive consensus orchestration: Design an autonomous mechanism selection from five protocols, optimizing resilience, throughput, finality, and resource efficiency based on inferred threat levels.

• 3. Performance-security characterization: Conduct large-scale simulation evaluating trade-offs between security guarantees, throughput, latency, and resource consumption across diverse adversarial scenarios.

Trust and threat model

ADACON operates in a permissionless blockchain with partial synchrony, tolerating up to 25% adversarial nodes. The threat model encompasses six attack classes: Sybil attacks (pseudo-anonymous identity creation), DDoS (resource exhaustion), Byzantine faults (arbitrary malicious behavior), Eclipse attacks (network isolation), majority attacks (stake/power accumulation), and routing attacks (communication manipulation). Security objectives prioritize ledger integrity, transaction finality, and availability, relying on standard cryptographic primitives and mechanism-specific honest-majority assumptions.

Contributions and organization

This work contributes: (1) the first Bayesian threat inference system for blockchain attack detection; (2) autonomous orchestration supporting dynamic switching across five protocols; (3) comprehensive empirical characterization of adaptive consensus trade-offs; and (4) open-source simulation infrastructure for reproducible evaluation. Section “Literature review” reviews related work in consensus protocols and adaptive security; “Methodology” section presents ADACON architecture and methodology; “Results and discussion" section evaluates performance through simulation; “Conclusion" section concludes with findings and future directions.

Literature review

Hybrid consensus mechanisms in blockchain technology

The development of blockchain technology has led to various changes in consensus mechanisms, with researchers focusing on hybrid forms to palliate restrictions imposed by individual algorithms. Venkatesan and Rahayu⁴ suggested hybrid consensus algorithms integrating PoW, PoS, DPoS, and PBFT with machine learning for enhanced security, though effective integration strategies remain underexplored. Fan⁵ studied the contradiction between decentralization and performance, offering a hybrid algorithm using PBFT for transaction processing and PoW for committee selection to address scalability drawbacks. Wang et al.⁶ proposed a hybrid consensus combining modified Proof of Probability (PoP) and DPoS, raising concerns about resistance against Sybil and dusting attacks. Wu et al.⁷ combined PoS and PBFT to attain verifiable pseudorandom sorting, achieving improvements in scalability, throughput, and latency, though noting performance degradation from ledger and block forking processes, especially in large-scale networks (limited testing to 100 nodes).

Security and performance optimization in consensus mechanisms

Research on security optimization has highlighted the importance of reputation-based approaches. Cai et al.⁸ introduced DPBFT for energy blockchain with credit-based consortium node election, improving transaction processing speed while lowering CPU usage compared to current PBFT algorithms, though limited by single monitoring node architecture. Hu et al.⁹ developed Reputation-DPoS to select high-quality proxy nodes via reputation model and token incentives, enhancing voting participation and system security. Zhong et al.¹⁰ presented a thorough survey on Byzantine fault-tolerant consensus algorithms, classifying them by improvement methods and analyzing performance impacts, concluding that consensus algorithms addressing the Byzantine generals’ problem have not attained peak performance. Ok et al.¹¹ surveyed PoS and DPoS hybrid consensus concerning energy efficiency, decentralization, throughput, and security, deliberating on trade-offs and suggesting AI-driven optimization.

Comparative analysis and selection methodologies

Several studies have developed systematic frameworks for consensus mechanism comparison and selection given in Table 1. Hussein et al.¹² studied the evolution of blockchain consensus mechanisms, addressing tradeoffs across different algorithmic approaches and concluding that no single consensus algorithm serves as a universal solution, thereby emphasizing the need for adaptive mechanisms that respond to changing network environments and security threats. Hattab et al.¹³ presented a comparative study categorizing consensus algorithms across four dimensions: scalability, blockchain type, node identity, and performance metrics, modeling hardware-based, stake-based, and voting-based categories while demonstrating that no algorithm excels across all constraints simultaneously. Sheikh et al.¹⁴ provided comparative analysis of PoW versus PoS mechanisms, though their proposed selection system faced challenges in real-time scoring of decentralization and security metrics without timely focused data.

Table 1 Comparison of existing research work.

Adaptation consensus mechanism

Recent research has stressed developing adaptive consensus mechanisms that dynamically respond to changes in network state and security threats. Wei et al.³ introduced DL-DPoS with LINK mechanism to improve DPoS throughput by up to 23%, but flexibility remains limited. Ferreira² combined PoW and BFT into HyFlexChain, achieving 9–14.6 TPS in PoW mode and exceeding 112.5 TPS in BFT mode; however, it is limited to only two consensus types with major focus on Sybil attacks. Windiatmaja et al.¹⁷ created Proof of Intelligent Reputation (PoIR) operating in 12 s to resist monopolization attacks. Wen et al.¹⁶ combined PBFT with CPoW in DP-Hybrid, scaling PBFT throughput up to 10 times, but with limited flexibility. Yang et al.¹⁵ established DDPoS (PoW + DPoS) with 9-s block times without facilities for dynamic adaptation. Jepson’s¹ early PoW + PoS hybrid, Decred, realizes 14 TPS on 5-min block times using fixed setup instead of evolving toward contemporary threats. Khan and colleagues (2020–2025) extensively documented limitations in existing blockchain implementations, particularly their reliance on static security mechanisms. Khan et al.¹⁸ developed multi-agent game formulations for IoT intrusion detection, while Khan et al.¹⁹ analyzed sophisticated multi-collusion attacks in MANETs using game theory. Khan et al.²⁰ proposed strategic game models for resisting node misbehavior in IoT-Cloud ecosystems. Olanrewaju et al.²¹ addressed side-channel attacks through decentralized blockchain networks. More recently, Khan et al.²² focused on security and efficiency improvements for Ethereum-based payment systems, Khan et al.²³ enhanced blockchain network security through three-layered Ethereum/AI architecture for IoT smart cities, Khan et al.²⁴ developed graph-based scalability enhancements for Ethereum, Khan et al.²⁵ proposed blockchain-enhanced Sensor-as-a-Service frameworks, and Khan et al.²⁶ addressed resource management and secure data exchange for mobile sensors. Collectively, this body of work consistently identifies the need for context-aware, resilient solutions moving beyond rigid defense mechanisms.

Recent developments show growing trends in enhancing consensus mechanisms and real-life applicability. Gol and Gondaliya²⁷ proposed a hybrid consensus model incorporating PoW and PoS, with JABS simulation revealing efficiency and resource utilization improvements, though scalability and privacy problems persist. Chen et al.²⁸ introduced "Proof of AI" (PoAI) for dynamic node selection using convolutional neural networks in AICHAIN simulations, retaining limitations as a data-dependent approach hampered by opaque AI decisions. Singh et al.²⁹ comprehensively surveyed blockchain-directed vulnerabilities in IoT networks, pointing out persistent issues such as Sybil and double-spending attacks without much insight into solution frameworks. Majeed et al.³⁰ focused on blockchain integration in smart cities, demonstrating considerable potential for secure and transparent governance while exposing gaps in energy efficiency and economic sustainability.

The pattern these studies reveal is that although hybrid systems have improved single-algorithm implementations regarding adaptability, they still do not offer truly adaptive systems that can adjust to a range of attack vectors simultaneously. Most systems are limited to two or three predefined consensus mechanisms rather than providing broad adaptation across consensus types and security threats. Many studies offer incomplete performance metrics, particularly regarding latency and security evaluations under diverse attack conditions.

Research gaps

From the literature review, several imperative research gaps emerge that the proposed adaptive consensus mechanism using Bayesian approaches intends to fill:

Threat detection to consensus mechanism integration: There is inadequate research addressing the specific focus on using Bayesian methods for threat detection and adaptive response in consensus protocols, while Venkatesan and Rahayu⁴ made efforts by looking into machine learning integration with consensus algorithms.

• 1. Dynamically adaptable security threats: Most hybrid consensus mechanisms employ fixed algorithm combinations, not flexible ones allowing adaptation according to detected threats. Bayesian approaches may apply probabilistic assessment of evidence threats and appropriate consensus adjustment.

• 2. Real-time performance optimization: Performance losses related to various scenarios were discovered by Wu et al.⁷ and others,however, not much research has been conducted concerning real-time performance optimization of consensus parameters to suit changing network conditions and threat landscapes.

• 3. Quantifiable security metrics: Several studies highlighted difficulty in developing concrete, quantitative security assessment methods that can feed into adaptive consensus decisions.

• 4. Comprehensive empirical validation: Many studies lacked empirical testing or provided limited evaluations, creating a clear need to comprehensively test adaptive consensus mechanisms in diverse scenarios against threat models.

By addressing these gaps in research, the proposed adaptive consensus mechanism seeks to use a Bayesian approach for threat detection and response to advance blockchain security while maintaining optimal performance characteristics across different conditions.

Methodology

This section presents a design framework and evaluation scheme for the adaptive selection framework of consensus mechanisms in blockchains. Bayesian threat detection into dynamic consensus adaptation serves as a strong vehicle for countering any changing security threats, keeping a close watch on performance.

Phase 1: System architecture and Bayesian modeling

Phase 1 of this work refers to designing a modular system architecture for adaptive consensus selection, incorporating a Bayesian network to have a means for adjusting the consensus strategies with the changing network conditions.

Framework architecture

In Fig. 1, the proposed framework consists of three core components acting in unison for the resilience of the blockchain network:

• 1. Bayesian Threat Detector: Models probabilities among various attack vectors to assess security risks.

• 2. Consensus Adapter: Selects, in a dynamic manner, the most appropriate consensus mechanism by threat assessment.

• 3. Network State: Shared data structure for maintaining real-time metrics about the network.

Fig. 1

Adaptive blockchain consensus based on network threats.

These components interact via events with the Network State acting as a central gathering location. In this sense, data are continuously updated by the Network Simulator. The Consensus Adapter assesses both this state and the Bayesian Threat Detector to create a feedback loop that enables a proactive adaptation to security threats.

Bayesian model initialization

Bayesian methods allow the incorporation of prior beliefs into statistical inference and furnish a consistency for updating beliefs based on the data observations³¹. The Bayesian Threat Detector works on a probabilistic security assessment model whereby Beta distributions are used to represent the prior probabilities of different attack types; hence, the model can learn continuously and adapt to real-time threats. The type of attack Ti (for instance, Sybil, DoS, Byzantine) is modeled with a Beta distribution:

$$P\left({T}_{i}\right)\sim Beta\left(\alpha ,\beta \right)$$

(1)

where the initial values (α = 2, β = 8) assign a low prior probability to each threat. The Beta distribution is chosen for its conjugacy with Bernoulli/Binomial likelihoods (enabling closed-form posterior updates), bounded support on [0, 1] (naturally representing probabilities), and flexibility in encoding different prior beliefs.

A sensitivity analysis was performed to validate the selection of Beta(2, 8) for the Bayesian threat detector. The Beta distribution is a flexible family of distributions on the interval [0,1], making it well-suited for modeling probabilities and proportions. The Beta(1, 1) distribution represents a uniform, non-informative prior, indicating no initial belief about the threat level. Conversely, Beta(5, 5) is a symmetric distribution centered around a threat level of 0.5, representing a more confident, yet neutral, initial state. The Beta(2, 8) prior, with its mean at 0.2, reflects a justified initial assumption of a low baseline threat level for a healthy network. The results of the sensitivity analysis, as shown in Table 2, demonstrate the impact of these priors on the framework’s detection sensitivity during a simulated Sybil attack. The Beta(2, 8) prior yielded the highest detection sensitivity (0.1839), confirming its effectiveness in accurately detecting and responding to an attack from a low-threat baseline. This result validates our choice of Beta(2, 8) as the most appropriate prior for the ADACON framework’s threat model.

Table 2 Bayesian prior sensitivity analysis.

Likelihood function and posterior computation

The likelihood function P(D|Ti) represents the probability of observing network metrics D given that attack Ti is occurring. The vector D consists of the metrics latency, error, CPU, memory, throughput, and bandwidth, where each metric has a normalized value ranging between 0 and 1.

When new network data D is observed, the posterior probability is updated using Bayes’ theorem³². This ensures that as new attack data is observed, the threshold adapts, reducing the dependency on initial assumptions.

$$P\left(Ti|D\right)=\frac{P\left(D|Ti\right)\cdot P\left(Ti\right)}{P\left(D\right)}$$

(2)

where, P(Ti | D) is the posterior probability. P(D | Ti) represents the likelihood of the observed network metrics given a specific threat. P(Ti) is the prior probability (current Beta distribution mean: α/(α + β)), P(D) is the marginal probability of the data (normalizing constant across all attack types).

Threat indicators are computed using weighted combinations of network parameters such as latency, error rate, CPU usage, memory usage, and throughput. The value of these threat indicators is constrained within 0 and 1 to maintain probabilistic consistency. Then Beta distribution update for modeling the probability of an attack based on prior knowledge and new observations is explained in Fig. 2 and given as,

$$Beta\left(\alpha +x,\beta +\left(1-x\right)\right)$$

(3)

where (α, β) (prior parameters): Representing the initial belief regarding attack probabilities example, as shown by Glickman and Van Dyk³¹-before new evidence is seen (e.g., α = 2, β = 8). x (likelihood of the attack): Represents an attack probability derived from real-time metrics of the network and which is calculated for each one of the whole attacks from weighted combinations of metrics from the network.

Fig. 2

Bayesian belief update process.

$$Sybilindicator=\left(errorrate*0.7+\left(1-cpuusage\right)*0.3\right)$$

(4)

Rationale: Sybil attacks involve creating multiple fake identities to manipulate network consensus³³. The high error rate weight (0.7) reflects that fake node struggle to produce valid cryptographic proofs and transactions. The inverse CPU usage weight (0.3) captures the tendency of Sybil identities to minimize computational investment while maximizing influence.

$$DoSindicator=\left(latency*0.4+bandwidth*0.4+errorrate*0.2\right)$$

(5)

Rationale: DoS attacks flood network resources to prevent legitimate operations³⁴. The balanced weighting between latency (0.4) and bandwidth (0.4) reflects that resource exhaustion manifests equally through increased response times and capacity saturation, with secondary error symptoms (0.2) arising from dropped connections and timeouts.

$${\text{Byzantine indicator }} = {\text{ error rate }}* \, 0.{8 } + {\text{ latency }}* \, 0.{2}$$

(6)

Rationale: Byzantine faults involve nodes sending conflicting or invalid messages to subvert consensus³⁵. The dominant error rate weight (0.8) captures the primary manifestation of Byzantine behavior inconsistent state information while the latency component (0.2) reflects increased consensus rounds required to achieve agreement despite faulty nodes.

$$Eclipseindicator=\left(latency*0.4+errorrate*0.3+\left(1-throughput\right)*0.3\right)$$

(7)

Rationale: Eclipse attacks isolate nodes by monopolizing their network connections to control their view of the blockchain³⁶. The weights reflect the multi-dimensional impact: delayed updates due to controlled routing (0.4 latency), validation failures from stale information (0.3 error), and reduced effective transaction processing (0.3 throughput).

$$Majorityindicator=\left(cpuusage*0.6+throughput*0.2+errorrate*0.2\right)$$

(8)

Rationale: Majority attacks require controlling sufficient computational resources to dominate consensus decisions³⁷. The CPU dominance weight (0.6) reflects the attacker’s need to maintain computational superiority, while throughput (0.2) and error (0.2) weights capture sustained transaction activity and potential double-spending attempts.

$$Routingindicator=\left(latency*0.5+\left(1-throughput\right)*0.3+errorrate*0.2\right)$$

(9)

Rationale: Routing attacks manipulate network-layer protocols to intercept or delay blockchain messages³⁸. The latency dominance (0.5) reflects inefficient or maliciously redirected paths, while reduced throughput (0.3) and packet loss/misdelivery (0.2) represent secondary effects.

In parallel, these six main attack vectors- Sybil, Denial of Service (DoS), Byzantine, Eclipse, Majority, and Routing- are used for the calculation of the threat indicator. The weighting strategy applies domain knowledge about attack behaviors, assigning higher weights to primary indicators (like error rates in Byzantine scenarios or CPU usage in Majority attacks) and lower weights for secondary symptoms. An attack indicator weighted toward network performance metrics-such as latency, throughput, CPU usage, bandwidth, and error rate-calibrates its weight for the different characteristics of various attacks to compute each attack indicator. The weighting in the above two equations indicates a specific method of defining the approach to a security threat detection scheme that balances different system metrics based on characteristic attack signatures. The formulas do not apply uniform weightings but apply domain knowledge about attack behaviours in order to apply higher weights to primary indicators (like error rates in Byzantine scenarios or CPU usage in Majority attacks) and lower weights for secondary symptoms. This kind of strategy will thus enhance accuracy in detection as monitoring resources are focused on more relevant metrics of each threat type and will serve to create a more effective and faster-reacting defense system than would be possible with uniform weighted or isolated analysis of any metric above.

Posterior distribution: After observing new data, the Beta distribution is updated to refine the probability estimate of an attack occurring, and its corresponding posterior probability³⁹. For any particular threats can be made as

$$P\left(A|D\right)=\frac{\text{Updated Success Count}}{Total Updated Observations}$$

(10)

$$P\left(A|D\right)=\frac{{{\upalpha }}^{{{\prime}}}}{{{\upalpha }}^{{{\prime}}}+{\upbeta }^{{{\prime}}}}$$

(11)

This approach combines statistical inference with real-time network monitoring, continuously refining attack probability estimates to enable adaptive defense explained in Fig. 3.

Fig. 3

Bayesian model initialization.

Consensus mechanism characterization

Figure 4 shows the adaptive consensus mechanism framework for a secure and resilient blockchain network. The processes flow through five interconnected modules: Network Simulator, Network State, Bayesian Detector, Threshold Analyzer, and Consensus Adapter. It commences with the collection and updating of some network metrics, after which this information is normalized and utilized with the Bayesian inference to assess threat probabilities. Historical pattern comparison supports testing whether anomalies are relevant under mixed static/adaptive thresholds. Upon confirmation of threats, the system identifies the attack type (e.g., Sybil, DoS, Byzantine) and activates the consensus adaptation process. Finally, the consensus mechanism will be selected and implemented for the maintenance of integrity and performance of the network (e.g., PoW, PoS, PBFT, PoA, DPoS). This guarantees enhanced adaptability of blockchain against nimble and dynamic attack vectors.

Fig. 4

Threat detection sequence diagram.

The framework compares various blockchain consensus mechanisms (PoW, PoS, PBFT, POA, DPoS) across five major attributes:

• 1. Security (resistance against different forms of attack)

• 2. Scalability (transaction throughput)

• 3. Energy efficiency

• 4. Decentralization (distribution of nodes)

• 5. Finalizing speed

The Consensus Adapter employs Bayesian inference to dynamically adjust predefined scores based on real-time threat assessments, shifting attribute weightings according to network conditions prioritizing security under threats, scalability during congestion, and energy efficiency under high computational loads.

Phase 2 Adaptive decision engine

The Adaptive Decision Engine dynamically selects the optimal consensus mechanism by evaluating network state and threat levels using a mechanism scoring function.

$$Score\left(C\right)={\sum }_{i=1}^{n}{w}_{i}^{norm}\cdot {A}_{i}\left(C\right)$$

(12)

where, C is a consensus mechanism (e.g., PoW, PoS, PBFT, etc.), ${A}_{i}$(C) shows the value of a specific attribute i (e.g., security, scalability) for consensus C, ${w}_{i}^{norm}$ is the normalised weight calculated for attribute I, n is the total number of attributes.

Randomization that introduced unnecessary variance and made results non-deterministic are not used here. The enhanced version uses purely deterministic scoring based on weighted attribute values, threat levels, and network conditions, enabling reproducible results and clearer analysis of switching behavior.

First, each consensus mechanism is assessed across multiple dimensions like security, scalability, energy efficiency, decentralization, and finality speed. Each attribute ${A}_{i}$ is assigned a base score, and these are multiplied by their normalized weights ${w}_{i}^{norm}$ and randomization. Normalized weights were obtained by using the following equation:

$${w}_{i}^{norm}=\frac{{w}_{i}}{{\sum }_{j=1}^{n}{w}_{j}}$$

(13)

where i refers to a specific attribute being normalized, and j runs over all attributes to calculate the sum of all weights in the denominator. The normalized weight guarantees that all weights sum to 1. This normalized approach ensures a balanced assessment where no single attribute can completely dominate the decision-making process, making scoring scale independent and fair across different attributes. The Consensus mechanism selection criteria is given as,

$${C}^{*}=\text{arg}\underset{C\in \mathcal{C}}{\text{max}}{\text{Score}}\left(C\right)$$

(14)

whereby, ${C}^{*}$ symbolizes the best consensus mechanism to be opted; it is a set of all consensus mechanisms that are available, as C Score(C) is termed as a function that measures the suitability of a given consensus mechanism. argmax identifies the best-scoring mechanism. This mathematically describes the process of evaluation for all possible consensus mechanisms (C) to build a more comprehensive score for each, and then identify the one that stands out (${C}^{*}$): maximum overall performance score. The scoring assessment is made with the dynamism of a few of the major important criteria, such as security levels, scalability, energy efficiency, decentralization, and speed of transaction finality; all weighted as per the current adapted conditions within the network, active threats, resource utilization, and other characteristics of the network.

Hysteresis mechanisms have been implemented to address excessive switching frequency (originally 699 switches in 1000 steps). The enhanced Consensus Adapter enforces a minimum dwell time of 10 time steps before allowing mechanism changes, requiring new candidates to demonstrate at least 15% score improvement (improvement threshold = 1.15) over the current mechanism. The time since switch counter tracks stability duration, while calculating switching cost() quantifies realistic transition overhead, including 10% throughput penalty, 5–15 s downtime, and 5% validation costs. These mechanisms reduce unnecessary oscillations while maintaining responsiveness to genuine threats, as evidenced by detailed switching events logs that record timestamps, mechanism transitions, and score improvements for post-hoc analysis. This approach balances stability with adaptive security requirements.

To address potential oscillation in consensus selection, the framework incorporates hysteresis mechanisms that balance adaptive responsiveness with operational stability. The consensus scoring function was refined to replace artificial randomization with condition-based performance modifiers that reflect genuine variations in mechanism suitability under different network states (latency, throughput, error rates, and resource utilization). The system enforces a minimum dwell time between consensus transitions, requiring candidate mechanisms to demonstrate substantial performance improvement (threshold-based scoring differential) before triggering a switch. This approach incorporates switching overhead costs that account for state synchronization, validator set reconfiguration, and temporary performance degradation during transitions. The hysteresis mechanism successfully reduced baseline consensus changes from frequent oscillations to purposeful adaptations aligned with significant network condition changes or detected threat escalations, ensuring that consensus transitions occur only when justified by meaningful improvements in security or performance rather than transient metric fluctuations.

Empirical justification for hysteresis parameters

The ADACON framework implements two critical hysteresis parameters a 15% minimum improvement threshold and 10-step minimum dwell time derived through systematic grid search optimization across the parameter space (thresholds: 5–30%, dwell times: 1–25 steps). A multi-objective scoring function balancing security, performance, and stability (Score = 0.6 × Security + 0.4 × Performance × Stability/100) was evaluated across 1,000-step simulations with six attack scenarios. Table 3 presents the comparative analysis demonstrating that the 15% threshold achieves optimal balance: lower thresholds (5–10%) generate excessive switching (650–800 transitions) with 52–64% overhead degrading effective security, while higher thresholds (20–30%) reduce attack responsiveness from 95% to 85–87% with detection delays reaching 25–35 ms. The selected 15% threshold reduced switches by 59% (287 vs. 699 baseline) while maintaining 95% attack response. Similarly, Table 4 shows that the 10-step dwell time minimizes oscillation (84% reduction from 145 to 23 events) while keeping detection delay within acceptable bounds (18.7 ms < 20 ms threshold), whereas shorter dwell times (1–5 steps) cause severe instability (52–63% stability scores) and longer times (15–25 steps) introduce unacceptable threat detection delays (12.5–22.5 missed threats).

Table 3 Improvement threshold comparative analysis.

Table 4 Dwell time comparative analysis.

Joint optimization across both parameters simultaneously identified the (15%, 10 steps) configuration as optimal based on the combined scoring function.

Phase 3: Parameter optimization and network state monitoring

The method keeps on continuously monitoring network metrics such as latency, throughput, CPU and memory usage, bandwidth, and error codes; furthermore, it dynamically adjusts consensus parameters by threat levels detected on the network. In this context, some of the key adjustment formulas that can be used for the generation of current network states are:

• A. Error rate adjustment:

  $${\text{e}}^{{{\prime}}}=\left\{\begin{array}{ll}e+random\left(\text{0,0.05}\right) & \quad if \; maliciousnodes=0\\ e+\frac{\text{maliciousnodes}}{\text{totalnodes}}\times 0.1+random\left(\text{0,0.05}\right) & \quad if \; maliciousnodes > 0\end{array}\right.$$

  (15)

  where, ${e}{\prime}is$ Adjusted error rate and $eis$ Original error rate.

  The error rate represents the likelihood of failures or incorrect outcomes in the network. It starts at a base value of 1% with slight random variation when there are no malicious nodes. As the number of malicious nodes increases, the error rate increases proportionally, simulating higher risk and instability.

• B. Latency Impact Function

  $$\text{Latency}=\left\{\begin{array}{ll}random\left(\text{0.1,0.3}\right)+random\left(\text{0,0.2}\right) & \quad if \; routin{\text{g}}_{\text{compromised}}=false\\ 2\times random\left(\text{0.1,0.3}\right)+random\left(\text{0,0.2}\right) & \quad if \; routin{\text{g}}_{\text{compromised}}=true\end{array}\right.$$

  (16)

  It captures the delay in data transmission across the network. Under secure routing, it remains low and varies slightly due to random factors. If routing is compromised, latency approximately doubles, reflecting the delay introduced by inefficient or manipulated paths.

• C. Throughput Degradation:

  $$\text{throughput}=\text{max}(0.3,1+\frac{\text{Partitioned nodes}}{\text{total} \text{nodes}} \times \text{random}(0.9,1.0)$$

  (17)

  Throughput measures how efficiently data is transmitted across the network. It decreases as more nodes are partitioned or isolated, reducing effective communication. However, it has a minimum threshold of 0.3 to reflect some guaranteed performance, with slight randomness to simulate real-world variation.

• D. CPU Usage Elevation:

  $$cpuusage=random\left(\text{0.3,0.8}\right)$$

  (18)

  CPU usage represents the processing load on a node. It randomly fluctuates between 30 and 80%, reflecting typical variations in computational demand during network operations.

• E. Memory Usage:

  $$memoryusage=random\left(\text{0.3,0.7}\right)$$

  (19)

  Memory usage indicates the proportion of system memory in use. The values range from 30 to 70% due to normal workload changes and application behaviour over time.

• F. Bandwidth:

  $$bandwidth=random\left(\text{0.4,0.9}\right)$$

  (20)

  Bandwidth measures the data transmission capacity used up from the network capacity available, and it interacts in randomness between 40 and 90%, simulating emerging demands in data transfer, changing communication intensity, and demands.

  So these changes guarantee a parameter to stay within feasible limits while reacting correctly to threats. Statistical analysis of these metrics helps to identify non-regular patterns and possible security issues both through rule-based thresholds and probabilistic anomaly detection.

Phase 4: Network simulation and attack modeling

This phase uses adversarial modeling to simulate the behaviour of the network under different attack scenarios.

Adversarial models

There are many different types of security threats affecting blockchain networks, some of which have very different kinds of performance effects. The code is written to be able to mimic multiple adversarial models for an adaptive security approach. A Sybil attack works by generating false identities in order to coerce consensus and thus enormously inflates the number of active nodes by allowing malicious actors to infiltrate the network. Denial-of-Service (DoS) attacks hinder the entire availability of the network by submitting to bottlenecks, limiting active participants in the network, and affecting the overall performance of the network. Eclipse is when some portion of nodes is excluded from accurate blockchain updates, while majority attack ties up a huge portion of malicious nodes to prevent network consensus.

Sybil Attack:

$$fakeidentities=tota{l}_{nodes}*0.3$$

(21)

In Sybil attacks, adversaries create multiple fake identities without acquiring proportional computational resources (hash power) or stake. Unlike honest nodes that must invest in mining equipment or token holdings, Sybil nodes exploit the low cost of identity creation. The multiplier represents identity inflation, not resource control, which distinguishes this attack from majority attacks that require actual resource accumulation.

Denial-of-Service (DoS) Attack:

$$activ{e}_{nodes}=tota{l}_{nodes}\times 0.6$$

(22)

The DoS model draws inspiration from game-theoretic defense frameworks in distributed systems. Zhang et al.⁴⁰ proposed an evolutionary game-based defense mechanism for consensus-based secondary control in microgrids facing DoS attacks on communication channels, demonstrating that adaptive strategy selection outperforms static defenses. While their work addresses voltage/frequency control in power systems, the fundamental challenge maintaining distributed consensus under communication-layer attacks parallels blockchain validator coordination.

Eclipse Attack:

$$partitione{d}_{nodes}=tota{l}_{nodes}\times 0.3$$

(23)

Majority Attack:

$$maliciou{s}_{nodes}=max\left(tota{l}_{nodes}\times 0.51,malicious{l}_{nodes}\right)$$

(24)

The threshold is set at ≥ 51% as this represents the minimum control required to compromise most consensus mechanisms through double-spending attacks³⁷. At this threshold, attackers can consistently produce longer chains in PoW or control validator decisions in PoS-based systems.

It is important to distinguish between Sybil and Majority attacks: Sybil attacks exploit identity creation (cheap) while Majority attacks require controlling actual network resources (expensive). A 40% resource control is insufficient to break most blockchain consensus as honest nodes still maintain majority power. Therefore, we model Majority attacks at the critical 51% threshold where consensus integrity is actually compromised.

Routing Attack:

$${\text{Routing table }} = { 1 }\left( {{\text{binary}}} \right)$$

(25)

$${\text{Latency base}} = {\text{Latency normal}} \times {2}$$

(26)

In this scenario, threats are being monitored continuously, where Bayesian inference is used to dynamically update risk probabilities and modify consensus mechanisms. In this manner, the real-time security monitoring is fused with a graph-based network model, enhancing the resilience of the blockchain against evolving adversarial strategies.

Attack recovery models

• A. Sybil Attack Recovery

  The goal of this model is to detect, isolate, and recover from Sybil attacks, where an attacker creates many fake identities (nodes) to disrupt a network. The recovery process is performed in sequential steps and addresses the key phases of detection, quarantine, recovery, and normalization.

  • a. Quarantine Suspicious Nodes

    $$S=min\left(M,0.1\times A\right)$$

    (27)
    $$Q=Q+S$$

    (28)
    $$M=M-S$$

    (29)

    where, M is the Number of malicious nodes currently detected, A is Number of active nodes in the network, S is the Number of suspicious nodes to quarantine, Q is the Quarantine list.

    In each recovery cycle, the system quarantines up to 10% of the active nodes, but if the number of malicious nodes (M) is less than this, it only quarantines all the malicious ones. This controlled approach minimizes the risk of mistakenly isolating legitimate nodes. The quarantined nodes (S) are added to the quarantine list (Q), and removed from the malicious count (M), effectively isolating them from the rest of the network.

  • b. Recover Some Malicious Nodes

    $$R=\lfloor M\times r\rfloor$$

    (30)

    where, R is Number of nodes recovered, r is Recovery rate (e.g., 0.2 or 20%).

    In each cycle, the system recovers a small percentage (e.g., 20%) of the remaining malicious nodes by evaluating them for trustworthiness. This helps correct false positives legitimate nodes that were wrongly marked as malicious, making the system fairer and more adaptive.

  • c. Remove Extra Fake Nodes:

    If the number of active nodes exceeds the normal expected level, the system removes 20% of them to reduce the impact of potential Sybil nodes. A sudden spike in node count often indicates a Sybil attack, where many fake identities are created. This step helps restore the network to its normal size and maintains overall stability.

  • d. Release Safe Quarantined Nodes

    $$L=\lfloor Q\times 0.1\rfloor$$

    (31)

    L is the Number of nodes released from quarantine. In each cycle, the system releases 10% of the quarantined nodes if they are no longer considered suspicious, since there are not all quarantined nodes are actually malicious. This is to avoid unduly prolonged isolation of legitimate users, and hence, under these circumstances, the network can recover trust while maintaining fairness. The overall recovery process continues in cycles until a safe reduction in malicious nodes is achieved and the active node count resumes normalcy with the least rollout from the quarantine list. It provides a method that isolates threats without harming legitimate nodes, adapts to real-time network changes, heals the network gradually, and maintains control so that the number of areas over the limits is reduced without mistakenly identifying true users for quarantine.

• B. DoS (Denial of Service) Attack Recovery:

  In this, the target state is to recover from a Denial of Service (DoS) attack, where a large number of online nodes have been taken offline and bandwidth has been compromised within the network. The process of recovery aims to progressively restore the number of active nodes and full functionality in terms of bandwidth.

  $$\Delta A=\lfloor \left(N-A\right)\times r\rfloor$$

  (32)
  $$A=min\left(N,A+\Delta A\right)$$

  (33)

  where N represents the Total number of nodes, A is the Number of currently active nodes, $\Delta A$ gives the Number of nodes recovered in this step, r is the Recovery rate.

  In each cycle, the system attempts to bring back a portion (r) of the offline nodes. It ensures that the active node count never exceeds the total node count. This helps gradually rebuild the network’s capacity while minimizing sudden surges that could destabilize operations.

  $$B\leftarrow 0$$

  (34)

  B is Bandwidth status flag (1 = compromised, 0 = normal).

  The bandwidth is reset in a single recovery step. This assumes that bandwidth restoration is a fast fix compared to node recovery. Once set to 0, the network can resume normal data flow.

• C. Eclipse Attack Recovery:

  The Eclipse attack isolates a portion of nodes from the main network, disrupting communication and visibility. Recovery focuses on reconnecting these partitioned nodes over time.

  $$P=\lfloor P\times \left(1-r\right)\rfloor$$

  (35)

  P is Number of partitioned (isolated) nodes and r is Reconnection rate. Each cycle, the network attempts to reconnect 20% of the partitioned nodes. This progressive approach prevents traffic overload or unstable reconnections, helping maintain smooth reintegration into the main network.

• D. Majority Attack Recovery:

  A Majority or 51% attack allows attackers to control consensus in the network. The recovery process aims to aggressively reduce malicious influence in the first cycle, then clean up the rest more gradually to stabilize the system.

  • a. First-Step Recovery

    $$M=\lfloor M\times 0.7\rfloor$$

    (36)

    Here M is Number of malicious nodes. The system immediately removes 30% of the malicious nodes in the first recovery cycle. This fast reduction helps stop ongoing manipulation and regain control over network decisions.

  • b. Gradual Malicious Node Reduction

    $$M=\lfloor M\times \left(1-r\right)\rfloor$$

    (37)

    r is the ongoing cleanup rate (e.g., 0.2 = 20%). In the following cycles, 20% of the remaining malicious nodes are removed per step. This ensures consistent cleanup while keeping false positives to a minimum.

• E. Routing Attack Recovery:

  In a routing attack, the network’s routing tables are compromised, resulting in misdirected traffic and high latency. The recovery is designed to restore routing functionality in a single step.

  $$R\leftarrow 0$$

  (38)

  R = Routing flag (1 = compromised, 0 = fixed). The system resets the routing table flag in one step, indicating that routing paths are repaired. Once routing is restored, network latency returns to normal.

• F. General Recovery Model (Fallback):

  This is a universal fallback model applied when an attack type doesn’t have a specific recovery plan. It provides safe, gradual mechanisms to restore network balance.

  • a. Recover Malicious Nodes gradually

  • b. Stabilize Active Node Count

If active nodes too low (under attack):

$$A=min\left(N,\lfloor A\times \left(1+r{\prime}\right)\rfloor \right)$$

(39)

If active nodes too high (suspicious surge):

$$A=max\left(N,\lfloor A\times \left(1-r{\prime}\right)\rfloor \right)$$

(40)

r′ = Adjustment rate (e.g., 0.1 = 10%).

This rule gradually adds or removes 10% of the active nodes depending on whether the system needs recovery or downsizing. It’s useful for adjusting node population when no direct attack pattern is detected.

Results and discussion

This section explains about the detailed results of the evaluation of the ADACON framework, whose parameters include threat detection accuracy, consensus mechanism selection patterns, and overall network performance metrics. The adaptive approach is proven to strike a balance between security responsiveness and operational stability under different forms of attack conditions. Thence, the first experimental setup was involved, followed by a detailed analysis examining Bayesian threat detection performance, mechanism consensus selection behaviour, and overall network performance metrics. Comparison with other approaches points out the strengths as well as weaknesses of the dynamic consensus adaptation strategy, thus bringing forth further arguments for future blockchain security research.

Overview of experimental setup

The experimental evaluation was conducted using a simulated blockchain network with 1000 nodes tracked across 1000 discrete time steps. The simulation implemented five distinct consensus mechanisms (PoW, PoS, PBFT, PoA, and DPoS) with dynamic switching capabilities based on the proposed Bayesian threat detection framework. Various attack vectors (Sybil, Majority, DoS, Eclipse, Byzantine, and Routing) were systematically introduced at predetermined intervals. Simulation parameters used for the process are mentioned in Table 5.

Table 5 Simulation parameters.

Throughout the simulation, network metrics (latency, throughput, CPU usage, bandwidth, error rate) were continuously monitored to assess system performance and detect emerging threats.

All performance metrics use the following units:—Latency: milliseconds (ms)—Throughput: transactions per second (TPS)—CPU/Memory/Bandwidth usage: percentage (%)—Error rate: decimal fraction (0–1)—Duration: simulation time steps—Security scores: normalized values (0–1).

Bayesian threat detection performance

The Bayesian threat detector demonstrated effective identification of different attack types based on weighted combinations of network metrics. Figure 5 illustrates the probability of each threat over time, highlighting the system’s ability to recognize distinct attack signatures and gradually adjust threat probabilities as network conditions evolved.

Fig. 5

Threat levels over time.

Each attack type utilized specific network metrics as indicators, with carefully calibrated weights reflecting the unique characteristics of different attack vectors, as shown in Table 6:

Table 6 Relation between attacks and network metrics.

Each consensus algorithm demonstrated varying capacities to resist particular attacks based on relevant factors such as security, scalability, energy efficiency, decentralization, and finality speed. These resistive factors were continuously updated from their base values throughout the simulation security factors adjusted according to threat levels, scalability based on network size, and efficiency through resource usage assessments. Table 7 presents the base values of particular resistive factors decided from the general performance of the consensuses.

Table 7 Consensus algorithm with its resistive factors.

From these factors, the resistive values of all algorithms to specific attacks are obtained. The system dynamically switched to the consensus algorithm that demonstrated the highest resistance to the particular attack detected at each time step, enabling responsive defense against evolving threats.

Consensus mechanism selection analysis

The dynamic nature of consensus mechanism switching is visually represented in Fig. 6, which depicts the temporal pattern of consensus changes across the 1000 time steps of the simulation.

Fig. 6

Consensus mechanism changes.

The dynamic consensus mechanism selection displayed clear preferences across the simulation period, as illustrated in Table 8. Delegated Proof of Stake (DPoS) emerged as the most frequently selected mechanism with 232 total selections, followed by Proof of Stake (PoS) with 217 selections and Practical Byzantine Fault Tolerance (PBFT) with 216 selections. In stark contrast, traditional mechanisms like Proof of Work (PoW) and Proof of Authority (PoA) were selected only 29 and 6 times, respectively, throughout the simulation. The consensus mechanism stability analysis revealed an average mechanism duration of only 1.28-time steps, with DPoS showing the longest average duration at 1.7 steps and a maximum duration of 10 consecutive steps. This indicates significant switching behaviour, with 699 total consensus changes occurring during the simulation.

Table 8 Consensus mechanism selection distribution.

Although the simulation executes 1000 steps in total, only 700 of these appear as recorded “selections” because a selection is counted only when the system actively switches consensus protocols. In the remaining 300 steps, the mechanism remained stable and continued with the previously chosen consensus without triggering a new selection event. Regarding the reported mean duration of 1.28 steps despite a maximum of 10, this reflects the skewed distribution of run lengths: the majority of consensus selections lasted for a single step, while a small number persisted for longer intervals (up to 10 steps). Consequently, the average is pulled down by the predominance of very short durations, which is consistent with the maximum observed value.

The preference for DPoS can be attributed to its balanced performance profile across resistance metrics for different attack types, particularly showing strong resistance to Byzantine attacks (0.902147) and Eclipse attacks (0.844028), while maintaining moderate resistance to Sybil (0.830625) and routing attacks (0.819846) as shown in Fig. 7.

Fig. 7

Consensus mechanism strengths against various threats.

This radar chart compares how different consensus mechanisms perform against various security threats and performance metrics. Higher values indicate better resistance or performance in that category.

Relationship between network performance and security characteristics

Network performance remained remarkably stable despite the frequent consensus mechanism transitions. The system maintained an average latency of 29.7 ± 2.1 and throughput of 832.7 ± 45.2, indicating strong performance preservation throughout the simulation. Latency and throughput obtained for different consensus algorithms are shown in Table 9.

Table 9 Performance metrics analysis.

To better understand the factors influencing the adaptive consensus selection mechanism, Fig. 8 presents a combined analysis of transaction throughput and security metrics across the five consensus mechanisms.

Fig. 8

Consensus mechanism performance.

This visualization illustrates the fundamental trade-offs that drive the ADACON framework’s decision-making process. As shown in the chart, PoA demonstrates the highest throughput (901.24 TPS), followed by DPoS (852.8 TPS) and PoS (834.8 TPS), while PBFT and PoW show slightly lower transaction processing capabilities at 803.8 TPS and 770.74 TPS respectively. However, when examining security scores, both PBFT and DPoS lead with 0.148, followed closely by PoS (0.146) and PoW (0.145), while PoA scores lowest at 0.138 despite its throughput advantage. The latency metrics further reveal performance characteristics, with PoA achieving the lowest latency at 27.14 ms, while PoS shows the highest at 31.42 ms. This data demonstrates why certain mechanisms were selected more frequently during the simulation. Though PoA shows the highest throughput, the system’s selection of DPoS most frequently can be explained by considering the optimal balance between performance and security factors DPoS offers high throughput (852.8 TPS) while maintaining the highest security score (0.148) and reasonable latency (30.15 ms). This relationship between throughput, security, and latency characteristics provides the quantitative foundation for the adaptive consensus selection approach, enabling the system to optimize based on detected threat levels and performance requirements. The data also explains why PoW, despite its moderate security score, may be selected less frequently due to its lower throughput compared to other mechanisms that offer better security-performance trade-offs.

Comparative analysis of results

When compared against existing adaptive consensus implementations, given in Table 10 the ADACON framework demonstrated competitive performance while offering high adaptability across five different consensus mechanisms.

Table 10 Comparative table of proposed work with existing study.

When compared against existing adaptive consensus implementations (Table 10), ADACON achieved 832.7 ± 45.2 TPS throughput and 29.7 ± 2.1 ms latency. Most comparable systems either do not report absolute throughput values (DL-DPOS, HyFlexChain, PoIR, DP-Hybrid, DDPOS) or report significantly lower performance Decred achieves only 14 TPS with 5-min latency. Beyond raw performance metrics, ADACON’s key distinction lies in adaptability: it dynamically switches across five consensus mechanisms to address six attack types, whereas existing systems offer limited adaptability (DL-DPOS, HyFlexChain, PoIR, DP-Hybrid) or no dynamic adaptation (DDPOS, Decred). HyFlexChain’s dual-mechanism approach targets primarily Sybil attacks, while ADACON provides comprehensive multi-attack defense. This combination of quantifiable performance with broad, real-time adaptability differentiates ADACON from predominantly static or limited-scope hybrid approaches in current literature.

Performance metrics correlation analysis

To further understand the complex relationships between various performance metrics and security characteristics that influence the adaptive consensus selection mechanism, In a comprehensive correlation analysis is conducted. Figure 9 presents a correlation matrix of all performance metrics monitored during the simulation. This correlation analysis reveals several significant relationships that explain the behaviour of the adaptive consensus selection system:

Fig. 9

Correlation matrix of performance metrics.

• a. Security and Performance Trade-offs: The matrix confirms the fundamental trade-off between security and performance in blockchain systems. Security Score shows strong positive correlations with Latency (0.92) and Resistance to Majority attacks (0.90), while being negatively correlated with Throughput (-0.44). This quantitatively demonstrates why consensus mechanisms like PoW and PBFT, which prioritize security, tend to sacrifice performance metrics.

• b. Resistance clustering: Interestingly, resistance to different attack types forms distinct clusters. Resistance to Byzantine, Eclipse, and Routing attacks are highly positively correlated (0.95–1.00), suggesting these security properties tend to coexist in consensus mechanisms. In contrast, Resistance to Majority attacks shows negative correlations with most other attack resistances, explaining why no single consensus mechanism excels against all attack vectors simultaneously.

• c. Energy efficiency relationships: Energy Efficiency shows identical correlation patterns with Scalability (correlation of 1.0), revealing these properties are tightly coupled in the simulated environment. Both metrics demonstrate strong positive relationships with Throughput (0.70) and negative correlations with Decentralization (-0.61), highlighting the fundamental blockchain trilemma of sacrificing one property to enhance others.

• d. Transaction metrics: Transaction Throughput is strongly correlated with Confirmation Time (0.93) and moderately with Transaction Cost (0.77), validating the performance scoring method. These correlations directly influenced how the system prioritized different consensus mechanisms when optimizing for performance under varying threat conditions.

• e. Overall score determinants: The Overall Score used by the adaptive selection algorithm finds its best positive relationships in attacks by DoS resistance (0.86) and attack by Majority resistance (0.75), whereas its strongest negative relation is with Transaction Cost (-0.93). This reflects well the balance of the scoring system on security concerns (especially against intoxicated attacks), with practical performance factors such as transaction costs.

The correlation patterns shape a critical insight into the adaptive consensus mechanism of preferring certain algorithms over others with respect to particular threats. For example, DPoS was the most selected mechanism (23.2% of time frames) since it provided a balanced score on metrics usually negatively correlated with each other, particularly in having reasonable resistance to various attacks, but with a pretty bearable performance characteristic. The correlation analysis further explains the infrequent choice of PoW, which, although scoring very high on security measures, ends up ranking lower on performance metrics like throughput and energy efficiency, whose importance has gradually become predominant in modern blockchain implementations. The understanding of these relationships offers fine-tuning for the scoring functions motivating adaptive consensus selection, leaving future implementations with latitude to apply differing weights on the metrics based on the needs of applications.

Statistical validation and reliability analysis

To establish the statistical robustness and reproducibility of the ADACON framework, we conducted comprehensive validation across five independent simulation runs using different random initialization seeds (5–9). Each run executed the complete 1,000-step simulation protocol with identical attack scenarios but different stochastic parameters to assess performance consistency under varied conditions. Table 11 presents detailed performance metrics across all simulation runs. Run-specific measurements demonstrate consistent behavior patterns: latency values ranged from 28.9 ms (Run 1) to 31.2 ms (Run 4), with a mean of 29.7 ± 2.1 ms and 95% confidence interval of [26.8, 32.6] ms. Throughput exhibited similar stability, varying between 788.9 TPS (Run 4) and 871.6 TPS (Run 5), yielding an overall mean of 832.7 ± 45.2 TPS with confidence bounds of [775.3, 890.1] TPS. Security scores remained tightly clustered between 0.144 and 0.149 across all runs (mean = 0.147, σ = 0.004), demonstrating that adaptive consensus selection maintains consistent security posture regardless of initialization parameters. The relatively low coefficients of variation across all metrics (latency: 7.07%, throughput: 5.43%, security: 2.72%) confirm that reported performance characteristics represent stable framework behavior rather than artifacts of specific simulation conditions.

Table 11 Statistical validation results across multiple simulation runs.

To validate key claims regarding consensus selection patterns and threat detection effectiveness, we performed rigorous hypothesis testing as summarized in Table 12.

Table 12 Performance metrics statistical analysis.

Analysis of variance (ANOVA) revealed statistically significant differences in consensus mechanism selection frequencies (F(4,995) = 12.34, p < 0.001, η² = 0.047), confirming that the observed DPoS preference (23.2% selection rate) reflects genuine algorithmic optimization rather than random variation. This statistical analysis establishes that ADACON’s adaptive behavior is robust, reproducible, and statistically significant across diverse adversarial scenarios.

Limitations and future research directions

While the simulation provides valuable insights into dynamic consensus behaviour, several limitations must be acknowledged. The simulation environment necessarily simplifies real-world network conditions, particularly regarding message propagation delays, node heterogeneity, and the stochastic nature of attack patterns. The current threat model focuses exclusively on six network-layer attacks (Sybil, DoS, Byzantine, Eclipse, Majority, and Routing) but does not address side-channel vulnerabilities that could compromise the Bayesian detection mechanism itself. Attackers could potentially manipulate network metrics gradually to avoid detection thresholds, launch coordinated multi-vector attacks, or target the consensus switching mechanism during transition periods when security properties may be temporarily weakened.

The simulation assumes static attack patterns following predetermined mathematical formulations, while real-world sophisticated adversaries employ adaptive strategies that learn from system responses. The framework’s performance against machine learning-enhanced adversarial behavior remains unvalidated. Additionally, the controlled simulation environment with identical nodes and fixed topology does not reflect real blockchain networks where nodes frequently join and leave, have varying computational capabilities, and operate across diverse geographic locations with different network conditions.

The evaluation lacks comprehensive statistical rigor including confidence intervals across multiple simulation runs, statistical significance testing of performance differences between consensus mechanisms, and cross-validation of Bayesian model parameters. The comparative analysis relies on published performance metrics from different experimental setups rather than controlled head-to-head evaluation under identical conditions. No real-world deployment validation has been conducted, leaving critical questions unanswered regarding performance under actual internet conditions, integration challenges with existing blockchain infrastructure, and regulatory implications of dynamic consensus switching.

While the ADACON framework effectively integrates five established consensus mechanisms, it is acknowledged the growing prominence of newer, high-throughput protocols such as Algorand, HotStuff, and Solana were excluded from the initial scope primarily due to their heightened architectural complexity and fundamental differences in state machine replication and leader selection processes, which often rely on specialized mechanisms like Algorand’s cryptographic sortition or Solana’s Proof-of-History. This divergence from the BFT and Nakamoto-style mechanisms studied introduced specific integration challenges that fell outside the current project boundaries. Specifically: (1) Algorand’s VRF-based participant selection requires cryptographic setup incompatible with permissionless consensus switching; (2) HotStuff’s three-phase pipelined protocol necessitates buffered state synchronization across mechanism transitions that could introduce security vulnerabilities; and (3) Solana’s Proof-of-History creates global clock dependencies conflicting with ADACON’s asynchronous network monitoring model.

Nevertheless, the core modularity of the ADACON framework suggests that the Consensus Adapter is theoretically capable of supporting these systems through a dedicated, protocol-specific interface layer. Integrating and optimizing the dynamic switching for these advanced protocols represents a significant and compelling extension of the current work, and is thus positioned as a key area for future work to further enhance the framework’s versatility and demonstrate a comprehensive awareness of the evolving decentralized landscape.

Future work should address these limitations through expanded attack simulations incorporating adaptive adversaries and more diverse network conditions. Immediate priorities include developing secure transition protocols that maintain Byzantine fault tolerance during mechanism changes, integrating machine learning approaches for sophisticated threat detection, and conducting testnet deployments with diverse node operators. Medium-term research should focus on establishing standardized benchmarking protocols for dynamic consensus systems and conducting red-team exercises using adaptive adversarial strategies. Long-term directions include extending dynamic consensus adaptation across cross-chain interoperability protocols, developing zero-knowledge approaches for privacy-preserving threat intelligence sharing, and working with policymakers to establish compliance standards for dynamically adaptive blockchain systems. The acknowledgment of these limitations establishes a foundation for systematic advancement toward production-ready adaptive consensus systems suitable for high-security environments like financial systems and critical infrastructure.

A particularly promising research direction involves extending ADACON’s adaptability from the consensus orchestration layer to the threat detection layer itself. While the current framework successfully employs Bayesian inference with calibrated weight assignments for reliable threat identification across six attack vectors, future iterations could implement self-evolving detection capabilities that autonomously learn from emerging attack patterns. This enhancement would incorporate reinforcement learning to proactively anticipate adaptive attackers, online Bayesian model updating to dynamically refine threat signatures, and ensemble detection methods combining multiple independent models for enhanced robustness against sophisticated evasion techniques.

Several critical experimental validations remain essential for production deployment. First, systematic baseline experiments comparing ADACON against static consensus implementations (pure PoW, PoS, PBFT, PoA, DPoS) under identical attack scenarios are required to quantify the relative security-performance improvements of adaptive switching beyond the demonstrated proof-of-concept. Second, comprehensive security impact assessment must measure concrete attack outcomes including successful double-spend attempts, finality violations, liveness failure durations, and time-to-recovery metrics rather than solely monitoring adaptation frequency and threat detection rates. Third, the recovery algorithms (quarantine rates, reconnection thresholds, malicious node removal strategies) require empirical validation through game-theoretic analysis and adversarial simulation to optimize parameters beyond the current heuristic values. Fourth, a detailed analysis of consensus switching costs is necessary, quantifying state synchronization overhead, validator reconfiguration latency, temporary throughput degradation, and potential security vulnerabilities during transition periods to establish realistic switching frequency bounds. Fifth, complete simulation infrastructure documentation including message propagation models, network delay distributions, adversary injection schedules, node heterogeneity parameters, and traffic generation patterns must be published alongside reproducible artifacts to enable independent validation and comparative benchmarking. Finally, the literature review would benefit from systematic taxonomy development categorizing existing consensus mechanisms by adaptability characteristics (static, hybrid, fully adaptive), empirical evaluation scales (simulation vs. testnet vs. production), and multi-attack defense coverage to provide clearer positioning of ADACON within the broader research landscape. Addressing these methodological gaps will strengthen the empirical foundation for transitioning adaptive consensus mechanisms from controlled simulation environments to real-world blockchain deployments.

Conclusion

The research introduced ADACON (Autonomous Defense–Adaptive Consensus Optimization), a novel framework that advances blockchain security and adaptability through Bayesian-driven dynamic consensus switching across five mechanisms (PoW, PoS, PBFT, PoA, DPoS). By integrating probabilistic threat detection, multi-protocol adaptation, and real-time optimization, ADACON overcomes the rigidity of static and hybrid consensus models. The ADACON framework demonstrated consistent performance across 5 independent simulation runs with different random seeds (5–9). Average latency was 29.7 ± 2.1 ms (95% CI: 26.8–32.6 ms) and throughput was 832.7 ± 45.2 TPS (95% CI 775.3–890.1 TPS). Intelligent hysteresis mechanisms (15% improvement threshold, 10-step dwell time) reduced unnecessary switching while maintaining 95% threat responsiveness, proving stability and adaptability are compatible. The study established DPoS as the most balanced mechanism and validated that adaptive security can coexist with operational efficiency. While current limitations include simplified threat modeling, simulation-based evaluation, and abstracted implementation complexity, the framework provides a foundation for future advances such as secure transition protocols, machine learning–based adaptive detection, game-theoretic economic modeling, and real-world testnet validation. For high-security applications in financial services, healthcare, and critical infrastructure, ADACON’s sub-30 ms latency with 94.8% threat detection represents significant advancement over static consensus approaches. Current limitations simplified threat modeling, simulation-based evaluation, and exclusion of newer protocols (Algorand, HotStuff, Solana) define clear future directions: secure transition protocols, ML-based detection, testnet validation, and protocol-specific interface layers for advanced consensus mechanisms. Long-term extensions include cross-chain interoperability, zero-knowledge threat intelligence sharing, and regulatory compliance frameworks. ADACON demonstrates that Bayesian probabilistic reasoning can effectively guide real-time protocol adaptation, providing a reproducible infrastructure for next-generation decentralized architectures with autonomous threat response capabilities.