A Cross-Layer Fault Injection Framework for Cascading Failure Analysis in Blockchain Systems

A Cross-Layer Fault Injection Framework for Cascading Failure Analysis in Blockchain Systems | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article A Cross-Layer Fault Injection Framework for Cascading Failure Analysis in Blockchain Systems Aneesh Senthil This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-9372666/v1 This work is licensed under a CC BY 4.0 License Status: Posted Version 1 posted You are reading this latest preprint version Abstract Blockchain systems underpin a growing class of decentralized applications where data integrity, fault tolerance, and consensus reliability are critical operational requirements. Despite their architectural strengths, real-world blockchain deployments remain susceptible to complex failure modes that span multiple system layers simultaneously. Existing reliability studies predominantly examine faults in isolation — targeting either smart contract logic, consensus protocol behaviour, or network communication — without accounting for the interdependencies that exist across these layers [14]. This narrow scope leaves a critical gap: cascading failures that originate in one layer and propagate through others remain poorly understood and systematically underexplored. This work addresses that gap by proposing a cross-layer fault injection framework that introduces controlled, reproducible faults across the application, consensus, and network layers within a unified simulation environment. The framework incorporates a fault propagation methodology that traces how localised faults amplify into system-wide degradation across layer boundaries. Evaluation across eight fault scenarios — ranging from isolated single-layer faults to simultaneous three-layer injection — produced measurable and consistent results. Cross-layer fault conditions increased transaction confirmation latency by 490% over baseline, reduced throughput by 80.3%, raised the fork rate to 12.7 per 100 blocks, and produced an error rate of 14.3%. These results demonstrate that single-layer fault analysis underestimates true system vulnerability by margins exceeding 70% across key performance metrics. The findings establish that holistic multi-layer fault analysis reveals vulnerability classes that single-layer methods cannot detect, and that the proposed framework provides a rigorous and reproducible foundation for evaluating end-to-end blockchain resilience. Theoretical Computer Science Blockchain Systems Fault Injection Testing Cross-Layer Analysis Smart Contract Vulnerabilities Consensus Protocols Network Fault Simulation Cascading Failures Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 INTRODUCTION Blockchain technology has matured beyond its cryptocurrency origins to become foundational infrastructure for decentralized applications across finance, healthcare, supply chain management, and digital identity systems. Its core value proposition rests on an append-only distributed ledger replicated across participating nodes, cryptographically enforced immutability, and consensus-driven transaction validation that eliminates dependence on centralized authorities [7]. Despite these strengths, real-world blockchain systems remain vulnerable to complex failure modes that span multiple system layers simultaneously. Faults arise from software defects in smart contract logic, inconsistencies in consensus mechanisms, and communication disruptions at the network layer. The critical issue lies not in these faults individually, but in their interactions. An invalid transaction at the application layer can propagate to disrupt consensus, while a network partition can desynchronise node states and trigger competing chain forks. However, the dominant reliability research approach continues to focus on single-layer fault analysis, leaving an entire class of cascading failure modes systematically undetected [6]. This work addresses that gap by proposing a cross-layer fault injection framework that operates across all three layers simultaneously, enabling the tracing of how faults propagate and amplify throughout the full blockchain stack [16]. 1.1 Motivation The motivation stems from a fundamental mismatch between blockchain’s theoretical fault tolerance and its practical behaviour under multi-layer failure conditions. The application, consensus, and network layers operate in close interdependence, making cross-layer fault propagation not only possible but structurally inevitable under degraded or adversarial conditions [15]. Single-layer testing fails to capture this behaviour, leaving critical compounding failures undetected until they surface in production deployments. 1.2 Contributions This work makes three concrete contributions. First, it introduces a cross-layer fault injection framework that controls faults across the application, consensus, and network layers within a single unified evaluation environment, a capability absent from existing single-layer approaches. Second, it presents a fault propagation methodology that traces cascading failure paths across layer boundaries, quantifying how localised faults amplify into system-wide degradation. Third, it provides experimental validation with measured latency, throughput, fork rate, and error rate data, demonstrating that cross-layer fault interactions produce significantly greater system degradation than equivalent single-layer faults in isolation. LITERATURE REVIEW Fault injection has long served as a primary empirical methodology for evaluating the dependability of complex distributed systems. The technique operates by deliberately introducing controlled faults into a running system and systematically observing how the system responds, degrades, or recovers [6]. In blockchain environments, this approach is particularly valuable because these systems are distributed, non-deterministic, and operate under adversarial conditions by design. However, existing blockchain fault injection research has largely developed along layer-specific lines, with studies targeting either the application, consensus, or network layer independently, and rarely considering how faults interact across layer boundaries. This section reviews the state of the art across each layer, identifies systemic limitations, and establishes the specific gap that motivates the proposed cross-layer framework. 2.1 Application Layer Fault Analysis The application layer, particularly smart contract security, represents the most extensively studied fault domain in blockchain research. Smart contracts are self-executing programs that enforce business logic without intermediary oversight, and their immutable deployment model makes pre-deployment vulnerability analysis critically important [9]. Atzei et al. [2] provide a comprehensive taxonomy of Ethereum smart contract vulnerabilities, identifying re-entrancy attacks, integer overflow errors, and improper access control as the most significant weakness classes. Luu et al. [8] extend this analysis using symbolic execution techniques to automatically detect exploitable vulnerabilities in deployed contracts. Despite their depth, these studies treat the smart contract environment as an isolated system and do not examine how application-layer faults propagate into the consensus or network layers. 2.2 Network Layer Fault Injection Network layer research focuses on how communication disruptions affect blockchain performance and consistency. Croman et al. [3] analyse scalability constraints of decentralised blockchain networks, demonstrating that propagation delays directly impair transaction throughput and consensus synchronisation. Eyal and Sirer [13] further establish a direct link between network behaviour and consensus integrity by showing that selective block withholding can undermine consensus fairness. However, these studies evaluate network faults primarily within the communication layer and do not trace how such disruptions propagate into consensus inconsistencies or application-level failures. 2.3 Consensus Layer Fault Studies Castro and Liskov [4] introduced Practical Byzantine Fault Tolerance, establishing the theoretical basis for consensus mechanisms that remain consistent despite up to one-third of nodes behaving maliciously. Dinh et al. [15] provide a systematic performance evaluation of multiple blockchain consensus protocols under varying workloads, demonstrating significant variation in throughput, latency, and fault tolerance across protocol designs. These studies consistently evaluate consensus mechanisms in isolation and do not model how application-layer anomalies or network disruptions can compound consensus-layer fault conditions. 2.4 System-Level Fault Injection and Limitations Zhang et al. [1] apply fault injection directly to blockchain node implementations, demonstrating that structured fault introduction can expose latent vulnerabilities that functional testing often misses. Liu et al. [5] examine fault tolerance in consortium blockchain systems under Byzantine conditions, quantifying throughput and latency degradation across multiple injection scenarios. Both studies advance the field but share a critical limitation. Neither introduces faults across multiple layers simultaneously, nor do they trace propagation paths through which faults in one layer trigger secondary effects in others. 2.5 Research Gaps Three persistent gaps emerge from this review. First, existing studies treat the application, consensus, and network layers as independent systems rather than tightly coupled components. Second, no existing framework traces cross-layer fault propagation paths. Third, the cumulative impact of simultaneous multi-layer faults on overall system performance remains unquantified. Table 1 Comparison of Existing Fault Injection Approaches in Blockchain Systems Study Layer Targeted Cross-Layer Analysis Fault Propagation Tracing Performance Metrics Reported Atzei et al. [2] Application No No No Luu et al. [8] Application No No No Croman et al. [3] Network No No Partial Eyal & Sirer [13] Network Partial No Partial Castro & Liskov [4] Consensus No No Partial Dinh et al. [15] Consensus No No Yes Zhang et al. [1] System-level No No Partial Liu et al. [5] System-level No No Yes Proposed Framework All Three Layers Yes Yes Yes 2.6 Positioning of the Proposed Work The gaps identified above collectively define the research space that this work occupies. Existing single-layer studies, while individually valuable, cannot detect the class of cascading failures that emerge through inter-layer interaction. A fault injection framework that operates across the application, consensus, and network layers simultaneously, and is instrumented to trace propagation paths between them, addresses a clear and consequential gap in the blockchain dependability literature. The proposed cross-layer fault injection framework is designed to address this gap by moving beyond the layer-bounded scope of prior work and enabling end-to-end resilience evaluation under realistic, interconnected fault conditions. PROBLEM STATEMENT AND OBJECTIVES The absence of a structured cross-layer fault propagation methodology constitutes a central gap in current blockchain dependability research. Existing frameworks evaluate faults under pre-defined, layer-bounded scenarios that do not reflect the dynamic conditions of real-world deployments, where multiple faults often occur simultaneously or in rapid sequence across different system components [1]. As a result, complex inter-layer failure patterns, particularly those most likely to arise in production environments, remain systematically under characterised. This gap motivates the need for a fault injection framework that operates across all three layers simultaneously, enabling structured analysis of propagation paths and cumulative performance degradation under realistic multi-fault conditions. In this context, this work purses four concrete and measurable objectives. The first objective is multi-layer fault modelling, involving the design of a structured framework that introduces controlled, reproducible faults across the application, consensus, and network layers within a unified evaluation environment. The second objective is fault propagation analysis, which systematically traces how faults originating in one layer trigger secondary effects in others and identifies the specific propagation paths through which localised failures escalate into system-wide degradation. The third objective is impact quantification, measuring the effect of cross-layer fault interactions on key performance indicators, specifically transaction confirmation latency, throughput, fork rate, and error rate, under both isolated and simultaneous fault scenarios. The fourth objective is comparative validation, evaluating the diagnostic capability of the proposed cross-layer framework against traditional single-layer approaches to demonstrate its ability to expose compounding vulnerabilities. Together, these objectives establish a complete evaluation pipeline that advances blockchain dependability research beyond the layer-bounded scope of existing work. PROPOSED METHODOLOGY Cross-Layer Fault Injection Framework The proposed framework provides a structured methodology for evaluating blockchain resilience through controlled, multi-layer fault injection and systematic propagation analysis. Unlike prior approaches that confine fault injection to a single architectural layer, the framework operates across the application, consensus, and network layers simultaneously, allowing end-to-end observation of how localised faults escalate into system-wide failures. The design prioritises reproducibility, configurability, and measurement precision, which are essential properties for credible dependability evaluation [6]. 4.1 System Architecture Blockchain systems are modelled in this work as three-layer stacks in which each layer performs a distinct function while maintaining tight operational coupling with the layers above and below. The application layer is responsible for smart contract deployment and execution, enforcing business logic and validating user-initiated transactions before they enter the processing pipeline. The consensus layer coordinates distributed agreement among participating nodes using configurable mechanisms such as Proof of Work, Proof of Stake, or Byzantine Fault Tolerance, determining which transactions are permanently appended to the ledger and in what order. The network layer manages the peer-to-peer communication fabric, handling transaction broadcasting, block propagation, and node synchronisation across the distributed topology [15]. The coupling between these layers is not merely logical but operational. Execution state at the application layer directly feeds into consensus inputs, while consensus correctness depends on network delivery guarantees. This interdependence forms the basis for cross-layer fault propagation and is not captured by single-layer testing methodologies. 4.2 Cross-Layer Fault Injection Model The fault injection engine forms the operational core of the framework. It introduces faults in a controlled and reproducible manner through three configurable parameters: the target layer at which the fault is injected, the fault type drawn from a predefined taxonomy for that layer, and timing and frequency parameters that govern when and how often the fault occurs during execution. This parametric design ensures that experiments are repeatable and that individual variables can be isolated for comparative analysis [14]. Faults are classified according to the layer in which they originate. At the application layer, injected faults model smart contract vulnerabilities, including missing input validation, re-entrancy conditions, and incorrect state variable updates, which produce malformed or semantically invalid transactions. At the consensus layer, faults simulate Byzantine node behaviour, invalid block proposals, and deliberate equivocation, conditions that stress the agreement mechanism and can induce competing chain forks. At the network layer, faults introduce communication disruptions such as configurable message delays, packet loss rates, and forced node disconnections, directly impairing block propagation and peer synchronisation. The framework supports both single-layer injection for controlled baseline measurement and simultaneous multi-layer injection for more realistic compound failure simulation. TABLE II Fault taxonomy across blockchain layers Layer Fault category Injected fault types Application Smart contract defects • Re-entrancy • Missing input validation • Integer overflow • Incorrect state update • Access control bypass Consensus Protocol-level faults • Byzantine node behaviour • Invalid block proposal • Double spending • Equivocation • Fork induction Network Communication disruptions • Message delay • Packet loss • Node disconnection • Partition injection • Broadcast suppression 4.3 Fault Propagation Analysis The propagation analysis module distinguishes this framework from prior single-layer approaches by explicitly tracking the paths through which a fault in one-layer triggers secondary effects in others. Rather than recording only whether a fault leads to system failure, the framework instruments each layer boundary to capture state transitions as fault effects move from one component to the next. A representative propagation chain illustrates this mechanism. A re-entrancy vulnerability at the application layer generates a sequence of malformed transactions. These transactions enter the network layer as broadcast messages and consume propagation bandwidth. Upon reaching the consensus layer, the malformed inputs stress block validation logic, increasing the probability of invalid block proposals and fork creation. Conversely, a network-layer partition that delays block propagation desynchronises node state, which the consensus layer interprets as competing valid chains, inducing a fork that subsequently causes the application layer to receive inconsistent ledger state for contract execution [4]. The framework records these propagation sequences as directed fault paths, capturing the originating fault type, the layer boundary crossed, the secondary effect triggered, and the resulting metric impact at each stage. This structured recording enables post-experiment analysis of fault amplification ratios, reflecting how a localised fault expands into broader system degradation, and helps identify inter-layer dependencies with the highest vulnerability concentration. 4.4 Experimental Workflow The experimental process follows a five-stage structured sequence designed to ensure systematic coverage of fault scenarios and reproducibility of results. In the first stage, the framework initialises a simulated blockchain network with a configurable number of nodes, establishing a stable baseline under fault-free conditions against which degraded performance is measured. In the second stage, the evaluator selects the target layer, fault type, and injection parameters through the fault injection engine interface. In the third stage, faults are injected during live transaction execution or block validation, depending on the target layer, ensuring that fault effects interact with active system behaviour rather than idle state. In the fourth stage, the system executes under controlled fault conditions while the monitoring engine continuously collects the four primary metrics, latency, throughput, fork rate, and error rate, at configurable sampling intervals. In the fifth stage, the collected data is analysed to extract fault propagation paths, quantify performance degradation relative to the baseline, and compare single-layer with multi-layer fault scenarios. All experiments are repeated across three injection modes: isolated single-layer faults, simultaneous multi-layer faults, and sequential fault injection, where faults are introduced in a defined order to simulate realistic compounding failure progressions. 4.5 Evaluation Metrics Four metrics are employed to quantify the impact of injected faults on system behaviour. Transaction confirmation latency measures the elapsed time from transaction submission to permanent ledger inclusion, capturing the cumulative delay introduced by fault-induced processing overhead at each layer. Throughput measures the number of transactions successfully processed per unit time, providing a direct indicator of system capacity degradation under fault load. Fork rate tracks the frequency at which competing chain branches emerge during consensus execution, reflecting how fault conditions affect the stability of distributed agreement. Error rate records the proportion of transactions that fail validation or are rejected during execution, capturing the direct impact of application and consensus layer faults on correctness. Table III Evaluation metrics, measurement methods, and primary fault drivers. Metric Unit Measurement method Primary fault driver Latency Milliseconds (ms) Time from tx submission to ledger inclusion, averaged over 100 tx samples Network delay; Consensus overhead Throughput Tx / second (TPS) Count of successfully committed transactions per 60-second window Multi-layer faults; Packet loss Fork rate Forks / 100 blocks Count of chain splits per 100 produced blocks across all nodes Byzantine nodes; Network partition Error rate % of total tx Ratio of rejected or failed transactions to total submitted transactions Contract faults; State corruption EXPERIMENTAL EVALUATION AND RESULTS 5.1 Experimental Setup The proposed framework was evaluated in a simulated blockchain environment comprising 10 peer nodes, configured to approximate a realistic distributed deployment. The simulation modelled interactions across all three architectural layers, application, consensus, and network, under eight distinct fault scenarios ranging from isolated single-layer faults to simultaneous injection across all three layers. The consensus mechanism used in the evaluation was a BFT-based protocol, consistent with consortium blockchain deployments where Byzantine fault tolerance is a primary reliability requirement [4]. Each experiment was executed over a fixed 300-second window with a constant transaction submission rate of 150 transactions per second. Reported results represent averages over five independent runs to account for non-deterministic network behaviour. Baseline measurements were collected under fault-free conditions prior to each injection run, providing a stable reference for quantifying performance degradation. 5.2 Impact on Transaction Latency Experimental results showed a clear and monotonic increase in transaction confirmation latency as fault scope expanded from single-layer to multi-layer conditions. Under fault-free baseline conditions, average confirmation latency was 210 ms. Single-layer application faults increased this to 310 ms, while isolated network-layer faults produced the highest single-layer latency at 430 ms, reflecting the direct impact of message delays on block propagation timing. Cross-layer combinations produced substantially greater degradation. Simultaneous application and network faults resulted in an average latency of 720 ms, and the three-layer scenario, with faults active across all layers simultaneously, produced a peak latency of 1240 ms, representing a 490% increase over baseline. This amplification indicates that cross-layer fault interactions do not combine linearly; instead, they compound through inter-layer dependencies, leading to repeated validation attempts and accumulation of unresolved state across components. 5.3 Impact on Throughput System throughput exhibited consistent degradation as fault complexity increased. Baseline throughput under fault-free conditions was 142 transactions per second. Isolated single-layer faults reduced throughput moderately. Application-layer faults alone yielded 118 TPS, while network-only faults reduced throughput to 96 TPS as packet loss introduced retransmission overhead and delayed block delivery. The most severe degradation occurred under multi-layer conditions. Simultaneous consensus and network faults reduced throughput to 52 TPS, and the three-layer scenario produced a further reduction to 28 TPS, representing an 80.3% decline from baseline. This collapse reflects the compounding effect in which invalid transactions generated at the application layer consume consensus validation resources, while concurrent network disruptions delay the propagation of even valid blocks [3]. 5.4 Fork Rate and Error Rate Behaviour Fork rate and error rate results provide the clearest evidence of cross-layer fault amplification. Under baseline conditions, the fork rate was 0.4 forks per 100 blocks, representing the natural variance of the BFT consensus mechanism. Network-only faults increased this to 3.6, as delayed block propagation caused nodes to independently validate competing chain heads. The combination of consensus and network faults produced the most severe fork behaviour, yielding 8.4 forks per 100 blocks, more than double the network-only value, confirming that Byzantine node behaviour and propagation delays interact to destabilise distributed agreement [13]. Under three-layer fault conditions, the fork rate reached 12.7 and the error rate reached 14.3%, the highest values observed across all scenarios. These results show that single-layer analysis cannot capture the extent of degradation produced by concurrent multi-layer faults, as the amplification emerges through inter-layer interaction. 5.5 Fault Propagation Patterns Analysis of recorded propagation paths revealed consistent and directional fault propagation behaviour across all multi-layer scenarios. Application-layer faults propagated upward into the consensus layer in cases where malformed transactions were generated. Invalid state updates increased block rejection rates by an average of 34% compared to consensus-only fault baselines. Network-layer faults propagated into the consensus layer by inducing node desynchronisation. In 78% of network fault runs, propagation delays of 400 ms or more caused at least one fork event within the first 60 seconds of execution. Consensus-layer faults, in turn, propagated downward to the application layer by causing nodes to reject valid transactions during fork resolution periods, reducing effective application-layer throughput even in the absence of direct application-layer faults. These bidirectional propagation patterns indicate that blockchain layers are not only logically coupled but also operationally entangled, a property that single-layer fault injection frameworks cannot capture. 5.6 Comparative Analysis: Cross-Layer vs. Single-Layer Approaches A direct comparison between single-layer and cross-layer fault injection outcomes confirms the superior diagnostic capability of the proposed framework. Across all metrics, single-layer fault injection consistently underestimates actual system degradation. The maximum latency observed under any single-layer scenario was 430 ms, whereas the equivalent cross-layer scenario reached 1240 ms, representing a 188% underestimation. Single-layer throughput degradation reached a minimum of 96 TPS, while the cross-layer minimum was 28 TPS, a gap of 70.8%. Fork rates under single-layer conditions peaked at 3.6, whereas the cross-layer peak was 12.7, more than three times higher. These results show that evaluating blockchain resilience through isolated, layer-specific fault injection provides an incomplete and overly optimistic view of system vulnerability. Table IV Summary of experimental results across all fault scenarios Fault scenario Latency (ms) Throughput (TPS) Fork rate (/100 blk) Error rate (%) Severity Baseline (no fault) 210 142 0.4 1.2 — Application only 310 118 0.8 4.8 Low Consensus only 380 104 2.1 3.1 Low Network only 430 96 3.6 2.4 Moderate App + Consensus 610 71 4.2 8.6 Moderate App + Network 720 63 5.8 7.2 High Consensus + Network 850 52 8.4 6.1 High All three layers 1240 28 12.7 14.3 Critical DISCUSSION The experimental results show that fault interactions across blockchain layers do not combine additively but amplify multiplicatively, at a level that cannot be predicted through linear superposition of individual fault effects. This non-linear behaviour follows from the operational coupling between layers. Invalid transactions generated at the application layer enter the consensus pipeline as valid processing inputs, consuming validation resources and increasing block rejection rates. At the same time, network disruptions delay the propagation of both valid and invalid blocks, extending the window in which unsynchronised node states can be exploited [4]. The combined effect produces degradation that differs from single-layer scenarios not only in magnitude but also in behaviour. This observation highlights a critical limitation in fault-tolerant blockchain architectures. BFT consensus protocols are designed to tolerate up to one-third of nodes behaving arbitrarily, but this guarantee assumes bounded network delay and well-formed application-layer inputs. When network delays exceed propagation thresholds and application-layer faults increase invalid transaction volume, these assumptions no longer hold in practice, even without exceeding the Byzantine node threshold [5]. In domains such as finance and healthcare, where consensus failures carry significant consequences, this represents a risk that is not visible under single-layer evaluation. The limitations of single-layer fault analysis follow directly from this behaviour. Studies that evaluate smart contract vulnerabilities without considering concurrent consensus and network conditions cannot capture how invalid transactions affect consensus stability [2]. Similarly, network-level analyses conducted without application-layer stress do not reflect how propagation delays interact with transaction volume to induce forks. The results obtained here indicate that this gap leads to consistent underestimation of system degradation across all measured metrics. These findings have practical implications for system design and testing. Fault injection strategies should include simultaneous multi-layer fault scenarios as a standard evaluation component. The observation that network delays exceeding 400 ms triggered fork events in 78% of runs provides a useful reference point for configuring network parameters and timeout thresholds. The observed bidirectional propagation, where application-layer faults degrade consensus performance and consensus instability reduces application-layer throughput, suggests that resilience mechanisms should be designed across layers rather than within isolated components. The evaluation was conducted in a simulated 10-node environment using a BFT consensus mechanism, which is sufficient to demonstrate cross-layer effects, although validation across larger deployments and alternative consensus protocols such as PoW and PoS remains an open direction. CONCLUSION AND FUTURE WORK This paper presents a cross-layer fault injection framework for evaluating the end-to-end resilience of blockchain systems. The framework introduces controlled faults across the application, consensus, and network layers simultaneously, enabling systematic analysis of inter-layer fault propagation and its cumulative impact on system behaviour. Experimental results show that cross-layer fault conditions lead to significantly greater performance degradation than single-layer faults in isolation, with a 490% increase in confirmation latency, an 80.3% reduction in throughput, a fork rate of 12.7 per 100 blocks, and an error rate of 14.3% under three-layer fault conditions. These results indicate that single-layer fault analysis underestimates system vulnerability, as amplification effects from inter-layer interactions are not captured in isolated evaluations [6]. The findings suggest that blockchain fault tolerance guarantees, while theoretically sound, degrade under concurrent multi-layer failures. This has implications for how blockchain systems are tested and prepared for deployment in reliability-critical domains. The proposed framework provides a reproducible and configurable basis for conducting such evaluations across different blockchain configurations and fault scenarios. Several directions remain for future work. Extending the framework to larger node counts and public blockchain platforms would help validate the observed propagation behaviour under real-world conditions. Incorporating additional consensus mechanisms, particularly PoW and PoS variants, would improve the generalisability of the results. Integrating machine learning-based fault injection strategies could support more adaptive exploration of complex fault spaces beyond manually defined scenarios [12]. Finally, coupling the framework with automated recovery mechanisms would enable evaluation not only of how blockchain systems degrade under fault conditions but also how effectively they recover. Declarations Ethical Approval This manuscript does not involve studies with human participants, human data, human tissue, or animals. No ethical approval was required. Conflict of Interest The author declares no conflict of interest related to the content of this article. Use of AI Assistance AI-assisted tools were used only for formatting and minor language refinement. All technical content, including the framework design, analysis, and conclusions, is the author’s original work, and the author assumes full responsibility for the accuracy and integrity of the manuscript. Funding This research received no external funding. Author Contributions Aneesh Senthil contributed to the conceptualisation of the study, literature review, design of the cross-layer fault injection framework, experimental analysis, and preparation of the manuscript. Acknowledgement The author acknowledges the academic support and guidance received during the development of this work. Availability of Data and Materials The findings of this study derive from a simulated evaluation framework. No external datasets were used or generated during this work. References Zhang, X., Chen, J., Li, Y., 2020. Using fault injection to assess blockchain systems. arXiv preprint arXiv:2006.11597. Atzei, N., Bartoletti, M., Cimoli, T., 2017. A survey of attacks on Ethereum smart contracts. Proc. POST, 164–186. doi:10.1007/978-3-662-54455-6_8. Croman, K., et al., 2016. On scaling decentralized blockchains. Proc. FC, 106–125. doi:10.1007/978-3-662-53357-4_8. Castro, M., Liskov, B., 1999. Practical Byzantine fault tolerance. Proc. OSDI, 173–186. Liu, Y., Xu, X., Zheng, Z., 2024. Fault tolerance testing for consortium blockchain systems. Future Generation Computer Systems. Arlat, J., Costes, A., Crouzet, Y., Laprie, J., Powell, D., 1990. Fault injection for dependability validation. IEEE Trans. Software Engineering 16 (2), 166–182. doi:10.1109/32.44383. Nakamoto, S., 2008. Bitcoin: A peer-to-peer electronic cash system. Luu, L., et al., 2016. Making smart contracts smarter. Proc. CCS, 254–269. doi:10.1145/2976749.2978309. Wood, G., 2014. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Yellow Paper. Koopman, P., DeVale, J., 1999. Comparing robustness of POSIX systems. Proc. FTCS, 30–37. doi:10.1109/FTCS.1999.781040. Swan, M., 2015. Blockchain: Blueprint for a new economy. O’Reilly Media. Christidis, K., Devetsikiotis, M., 2016. Blockchains and smart contracts for IoT. IEEE Access 4, 2292–2303. doi:10.1109/ACCESS.2016.2566339. Eyal, I., Sirer, E.G., 2014. Majority is not enough. Proc. FC, 436–454. doi:10.1007/978-3-662-45472-5_28. Avizienis, A., et al., 2004. Basic concepts and taxonomy. IEEE Trans. Dependable Secure Computing 1 (1), 11–33. doi:10.1109/TDSC.2004.2. Dinh, D., et al., 2018. Untangling blockchain. IEEE Trans. Knowledge Data Engineering 30 (7), 1366–1385. doi:10.1109/TKDE.2017.2781227. Jayabalasamy, G., Pujol, C., Bhaskaran, K.L., 2024. Application of graph theory for blockchain technologies. Electronics. doi:10.3390/electronics13082787. Additional Declarations The authors declare no competing interests. Cite Share Download PDF Status: Posted Version 1 posted You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-9372666","acceptedTermsAndConditions":true,"allowDirectSubmit":true,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":620572724,"identity":"9b80a7d2-32b5-4064-8f2b-088dad48a054","order_by":0,"name":"Aneesh Senthil","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABZElEQVRIie2RvWrDMBCAzwjsxY5XBVPnFWQMmUKfxcKQLIV0DBQcC4O6tGuhZOhDBEJGB0O8+AEMyZAQ8FZwKbQY0lK5aajz072Dv+GEOH26Owmgpua/IvlgtkREW/Kp6uV2h/OzorOKbfkiqteh2fQlVjr4Wwn/VqhfJtU8tEm4K1NRDtFHwWxdTEFiD1GQY7Kk49S9XRVTzyOxO9/kcNkCRauaeDl3bS0BpBiUY0IyOkkpY/dJhEmS9URJ1/JRw6mWSa/ahsRBlkaUg0MQnSQz5ms8xESkcAjIAaSSitFK++9FwUGFBQ3yUCjjuxljH9wTSv9NKMNjRVwlg8bFsAvqN30S2URhLNA4KqvIQomOFSvt2oYmprBEYwaQroljxkYXSdR8TLI2Tkhs8UPFTN31S8E7wyejt3mFbUfVA2X18jz19EbsZngwuGnpelJV9g93+lP7zgHk0/Nn+FVqampqauAL0I2DK3wdgAIAAAAASUVORK5CYII=","orcid":"https://orcid.org/0009-0008-1758-2904","institution":"VIT-AP University","correspondingAuthor":true,"prefix":"","firstName":"Aneesh","middleName":"","lastName":"Senthil","suffix":""}],"badges":[],"createdAt":"2026-04-09 22:12:17","currentVersionCode":1,"declarations":{"humanSubjects":false,"vertebrateSubjects":false,"conflictsOfInterestStatement":false,"humanSubjectEthicalGuidelines":false,"humanSubjectConsent":false,"humanSubjectClinicalTrial":false,"humanSubjectCaseReport":false,"vertebrateSubjectEthicalGuidelines":false},"doi":"10.21203/rs.3.rs-9372666/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-9372666/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":106740633,"identity":"caa17002-4258-4a97-b8eb-fd74cf31b89a","added_by":"auto","created_at":"2026-04-13 03:16:16","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":37029,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003e\u003cstrong\u003eProposed cross-layer fault injection framework architecture.\u003c/strong\u003e\u003c/em\u003e\u003c/p\u003e","description":"","filename":"1.png","url":"https://assets-eu.researchsquare.com/files/rs-9372666/v1/4fcc03dc7a64ccc7933757be.png"},{"id":106740629,"identity":"4db7b927-0011-493a-a088-de09ee87360a","added_by":"auto","created_at":"2026-04-13 03:16:16","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":33664,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eFault propagation flow across application, consensus, and network layers.\u003c/em\u003e\u003c/p\u003e","description":"","filename":"2.png","url":"https://assets-eu.researchsquare.com/files/rs-9372666/v1/da206dd3a9c1872a2965d33f.png"},{"id":106994384,"identity":"7a15bda1-a1eb-46f1-9dbe-fc5ca9c24e19","added_by":"auto","created_at":"2026-04-15 15:08:09","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":49702,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eTransaction confirmation latency (ms) across eight fault scenarios. Values represent averages over five experimental runs. Baseline denotes fault-free conditions.\u003c/em\u003e\u003c/p\u003e","description":"","filename":"3.png","url":"https://assets-eu.researchsquare.com/files/rs-9372666/v1/8078f1510c99904ef03ba02d.png"},{"id":106960314,"identity":"9569d116-6252-493e-9acd-1aefc8e1d013","added_by":"auto","created_at":"2026-04-15 09:20:09","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":47135,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eSystem throughput (transactions per second) across eight fault scenarios. Values represent averages over five experimental runs. Baseline denotes fault-free conditions.\u003c/em\u003e\u003c/p\u003e","description":"","filename":"4.png","url":"https://assets-eu.researchsquare.com/files/rs-9372666/v1/d51b103f6be1f629fd4b6112.png"},{"id":106740632,"identity":"118046f0-3924-40d7-a1e4-27a139af7d85","added_by":"auto","created_at":"2026-04-13 03:16:16","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":66662,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cem\u003eFork rate (forks per 100 blocks) and error rate (% of total transactions) across eight fault scenarios.\u003c/em\u003e\u003c/p\u003e","description":"","filename":"5.png","url":"https://assets-eu.researchsquare.com/files/rs-9372666/v1/e2313002081f32c73f81233f.png"},{"id":106996309,"identity":"d9716981-7ccc-4598-8a93-0eed9f7e10ee","added_by":"auto","created_at":"2026-04-15 15:28:14","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1223574,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-9372666/v1/91bbe0d2-9055-46a4-a672-44da8cf560f8.pdf"}],"financialInterests":"The authors declare no competing interests.","formattedTitle":"\u003cp\u003eA Cross-Layer Fault Injection Framework for Cascading Failure Analysis in Blockchain Systems\u003c/p\u003e","fulltext":[{"header":"INTRODUCTION","content":" \u003cp\u003eBlockchain technology has matured beyond its cryptocurrency origins to become foundational infrastructure for decentralized applications across finance, healthcare, supply chain management, and digital identity systems. Its core value proposition rests on an append-only distributed ledger replicated across participating nodes, cryptographically enforced immutability, and consensus-driven transaction validation that eliminates dependence on centralized authorities [7]. Despite these strengths, real-world blockchain systems remain vulnerable to complex failure modes that span multiple system layers simultaneously. Faults arise from software defects in smart contract logic, inconsistencies in consensus mechanisms, and communication disruptions at the network layer. The critical issue lies not in these faults individually, but in their interactions. An invalid transaction at the application layer can propagate to disrupt consensus, while a network partition can desynchronise node states and trigger competing chain forks. However, the dominant reliability research approach continues to focus on single-layer fault analysis, leaving an entire class of cascading failure modes systematically undetected [6]. This work addresses that gap by proposing a cross-layer fault injection framework that operates across all three layers simultaneously, enabling the tracing of how faults propagate and amplify throughout the full blockchain stack [16].\u003c/p\u003e \u003cdiv id=\"Sec2\" class=\"Section2\"\u003e \u003ch2\u003e1.1 Motivation\u003c/h2\u003e \u003cp\u003eThe motivation stems from a fundamental mismatch between blockchain\u0026rsquo;s theoretical fault tolerance and its practical behaviour under multi-layer failure conditions. The application, consensus, and network layers operate in close interdependence, making cross-layer fault propagation not only possible but structurally inevitable under degraded or adversarial conditions [15]. Single-layer testing fails to capture this behaviour, leaving critical compounding failures undetected until they surface in production deployments.\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec3\" class=\"Section2\"\u003e \u003ch2\u003e1.2 Contributions\u003c/h2\u003e \u003cp\u003eThis work makes three concrete contributions. First, it introduces a cross-layer fault injection framework that controls faults across the application, consensus, and network layers within a single unified evaluation environment, a capability absent from existing single-layer approaches. Second, it presents a fault propagation methodology that traces cascading failure paths across layer boundaries, quantifying how localised faults amplify into system-wide degradation. Third, it provides experimental validation with measured latency, throughput, fork rate, and error rate data, demonstrating that cross-layer fault interactions produce significantly greater system degradation than equivalent single-layer faults in isolation.\u003c/p\u003e \u003c/div\u003e"},{"header":"LITERATURE REVIEW","content":" \u003cp\u003e Fault injection has long served as a primary empirical methodology for evaluating the dependability of complex distributed systems. The technique operates by deliberately introducing controlled faults into a running system and systematically observing how the system responds, degrades, or recovers [6]. In blockchain environments, this approach is particularly valuable because these systems are distributed, non-deterministic, and operate under adversarial conditions by design. However, existing blockchain fault injection research has largely developed along layer-specific lines, with studies targeting either the application, consensus, or network layer independently, and rarely considering how faults interact across layer boundaries. This section reviews the state of the art across each layer, identifies systemic limitations, and establishes the specific gap that motivates the proposed cross-layer framework.\u003c/p\u003e \u003cdiv id=\"Sec5\" class=\"Section2\"\u003e \u003ch2\u003e2.1 Application Layer Fault Analysis\u003c/h2\u003e \u003cp\u003eThe application layer, particularly smart contract security, represents the most extensively studied fault domain in blockchain research. Smart contracts are self-executing programs that enforce business logic without intermediary oversight, and their immutable deployment model makes pre-deployment vulnerability analysis critically important [9]. Atzei et al. [2] provide a comprehensive taxonomy of Ethereum smart contract vulnerabilities, identifying re-entrancy attacks, integer overflow errors, and improper access control as the most significant weakness classes. Luu et al. [8] extend this analysis using symbolic execution techniques to automatically detect exploitable vulnerabilities in deployed contracts. Despite their depth, these studies treat the smart contract environment as an isolated system and do not examine how application-layer faults propagate into the consensus or network layers.\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec6\" class=\"Section2\"\u003e \u003ch2\u003e2.2 Network Layer Fault Injection\u003c/h2\u003e \u003cp\u003eNetwork layer research focuses on how communication disruptions affect blockchain performance and consistency. Croman et al. [3] analyse scalability constraints of decentralised blockchain networks, demonstrating that propagation delays directly impair transaction throughput and consensus synchronisation. Eyal and Sirer [13] further establish a direct link between network behaviour and consensus integrity by showing that selective block withholding can undermine consensus fairness. However, these studies evaluate network faults primarily within the communication layer and do not trace how such disruptions propagate into consensus inconsistencies or application-level failures.\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec7\" class=\"Section2\"\u003e \u003ch2\u003e2.3 Consensus Layer Fault Studies\u003c/h2\u003e \u003cp\u003eCastro and Liskov [4] introduced Practical Byzantine Fault Tolerance, establishing the theoretical basis for consensus mechanisms that remain consistent despite up to one-third of nodes behaving maliciously. Dinh et al. [15] provide a systematic performance evaluation of multiple blockchain consensus protocols under varying workloads, demonstrating significant variation in throughput, latency, and fault tolerance across protocol designs. These studies consistently evaluate consensus mechanisms in isolation and do not model how application-layer anomalies or network disruptions can compound consensus-layer fault conditions.\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec8\" class=\"Section2\"\u003e \u003ch2\u003e2.4 System-Level Fault Injection and Limitations\u003c/h2\u003e \u003cp\u003eZhang et al. [1] apply fault injection directly to blockchain node implementations, demonstrating that structured fault introduction can expose latent vulnerabilities that functional testing often misses. Liu et al. [5] examine fault tolerance in consortium blockchain systems under Byzantine conditions, quantifying throughput and latency degradation across multiple injection scenarios. Both studies advance the field but share a critical limitation. Neither introduces faults across multiple layers simultaneously, nor do they trace propagation paths through which faults in one layer trigger secondary effects in others.\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec9\" class=\"Section2\"\u003e \u003ch2\u003e2.5 Research Gaps\u003c/h2\u003e \u003cp\u003eThree persistent gaps emerge from this review. First, existing studies treat the application, consensus, and network layers as independent systems rather than tightly coupled components. Second, no existing framework traces cross-layer fault propagation paths. Third, the cumulative impact of simultaneous multi-layer faults on overall system performance remains unquantified.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e\u003cdiv class=\"gridtable\"\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003ctable id=\"Tab1\" border=\"1\"\u003e \u003ccaption\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 1\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e\u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"5\"\u003e \u003c/colgroup\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colspan=\"5\"\u003e \u003cp\u003eComparison of Existing Fault Injection Approaches in Blockchain Systems\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003ctr\u003e \u003cth align=\"left\"\u003e \u003cp\u003eStudy\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eLayer Targeted\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eCross-Layer Analysis\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eFault Propagation Tracing\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003ePerformance Metrics Reported\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eAtzei et al. [2]\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eApplication\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eLuu et al. [8]\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eApplication\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eCroman et al. [3]\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNetwork\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003ePartial\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eEyal \u0026amp; Sirer [13]\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNetwork\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003ePartial\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003ePartial\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eCastro \u0026amp; Liskov [4]\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eConsensus\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003ePartial\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eDinh et al. [15]\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eConsensus\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eYes\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eZhang et al. [1]\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eSystem-level\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003ePartial\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eLiu et al. [5]\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eSystem-level\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNo\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eYes\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eProposed Framework\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eAll Three Layers\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eYes\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eYes\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eYes\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/table\u003e\u003c/div\u003e \u003cp\u003e\u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec10\" class=\"Section2\"\u003e \u003ch2\u003e2.6 Positioning of the Proposed Work\u003c/h2\u003e \u003cp\u003eThe gaps identified above collectively define the research space that this work occupies. Existing single-layer studies, while individually valuable, cannot detect the class of cascading failures that emerge through inter-layer interaction. A fault injection framework that operates across the application, consensus, and network layers simultaneously, and is instrumented to trace propagation paths between them, addresses a clear and consequential gap in the blockchain dependability literature. The proposed cross-layer fault injection framework is designed to address this gap by moving beyond the layer-bounded scope of prior work and enabling end-to-end resilience evaluation under realistic, interconnected fault conditions.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec20\" class=\"Section2\"\u003e \u003cp\u003e\u003c/p\u003e \u003c/div\u003e"},{"header":"PROBLEM STATEMENT AND OBJECTIVES","content":"\u003cp\u003eThe absence of a structured cross-layer fault propagation methodology constitutes a central gap in current blockchain dependability research. Existing frameworks evaluate faults under pre-defined, layer-bounded scenarios that do not reflect the dynamic conditions of real-world deployments, where multiple faults often occur simultaneously or in rapid sequence across different system components [1]. As a result, complex inter-layer failure patterns, particularly those most likely to arise in production environments, remain systematically under characterised. This gap motivates the need for a fault injection framework that operates across all three layers simultaneously, enabling structured analysis of propagation paths and cumulative performance degradation under realistic multi-fault conditions. In this context, this work purses four concrete and measurable objectives. The first objective is multi-layer fault modelling, involving the design of a structured framework that introduces controlled, reproducible faults across the application, consensus, and network layers within a unified evaluation environment. The second objective is fault propagation analysis, which systematically traces how faults originating in one layer trigger secondary effects in others and identifies the specific propagation paths through which localised failures escalate into system-wide degradation. The third objective is impact quantification, measuring the effect of cross-layer fault interactions on key performance indicators, specifically transaction confirmation latency, throughput, fork rate, and error rate, under both isolated and simultaneous fault scenarios. The fourth objective is comparative validation, evaluating the diagnostic capability of the proposed cross-layer framework against traditional single-layer approaches to demonstrate its ability to expose compounding vulnerabilities. Together, these objectives establish a complete evaluation pipeline that advances blockchain dependability research beyond the layer-bounded scope of existing work.\u003c/p\u003e"},{"header":"PROPOSED METHODOLOGY","content":"\u003ch2\u003eCross-Layer Fault Injection Framework\u003c/h2\u003e\u003cp\u003eThe proposed framework provides a structured methodology for evaluating blockchain resilience through controlled, multi-layer fault injection and systematic propagation analysis. Unlike prior approaches that confine fault injection to a single architectural layer, the framework operates across the application, consensus, and network layers simultaneously, allowing end-to-end observation of how localised faults escalate into system-wide failures. The design prioritises reproducibility, configurability, and measurement precision, which are essential properties for credible dependability evaluation [6].\u003c/p\u003e\u003ch2\u003e4.1 System Architecture\u003c/h2\u003e\u003cp\u003eBlockchain systems are modelled in this work as three-layer stacks in which each layer performs a distinct function while maintaining tight operational coupling with the layers above and below. The application layer is responsible for smart contract deployment and execution, enforcing business logic and validating user-initiated transactions before they enter the processing pipeline. The consensus layer coordinates distributed agreement among participating nodes using configurable mechanisms such as Proof of Work, Proof of Stake, or Byzantine Fault Tolerance, determining which transactions are permanently appended to the ledger and in what order. The network layer manages the peer-to-peer communication fabric, handling transaction broadcasting, block propagation, and node synchronisation across the distributed topology [15]. The coupling between these layers is not merely logical but operational. Execution state at the application layer directly feeds into consensus inputs, while consensus correctness depends on network delivery guarantees. This interdependence forms the basis for cross-layer fault propagation and is not captured by single-layer testing methodologies.\u003c/p\u003e\u003cp\u003e \u003c/p\u003e\u003ch2\u003e4.2 Cross-Layer Fault Injection Model\u003c/h2\u003e\u003cp\u003eThe fault injection engine forms the operational core of the framework. It introduces faults in a controlled and reproducible manner through three configurable parameters: the target layer at which the fault is injected, the fault type drawn from a predefined taxonomy for that layer, and timing and frequency parameters that govern when and how often the fault occurs during execution. This parametric design ensures that experiments are repeatable and that individual variables can be isolated for comparative analysis [14]. Faults are classified according to the layer in which they originate. At the application layer, injected faults model smart contract vulnerabilities, including missing input validation, re-entrancy conditions, and incorrect state variable updates, which produce malformed or semantically invalid transactions. At the consensus layer, faults simulate Byzantine node behaviour, invalid block proposals, and deliberate equivocation, conditions that stress the agreement mechanism and can induce competing chain forks. At the network layer, faults introduce communication disruptions such as configurable message delays, packet loss rates, and forced node disconnections, directly impairing block propagation and peer synchronisation. The framework supports both single-layer injection for controlled baseline measurement and simultaneous multi-layer injection for more realistic compound failure simulation.\u003c/p\u003e\u003cp\u003eTABLE II\u003c/p\u003e\u003cp\u003e \u003c/p\u003e\u003cdiv class=\"gridtable\"\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003ctable id=\"Taba\" border=\"1\"\u003e \u003ccolgroup cols=\"3\"\u003e \u003c/colgroup\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colspan=\"3\"\u003e \u003cp\u003eFault taxonomy across blockchain layers\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003ctr\u003e \u003cth align=\"left\"\u003e \u003cp\u003eLayer\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eFault category\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eInjected fault types\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eApplication\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eSmart contract defects\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e• Re-entrancy\u003c/p\u003e \u003cp\u003e• Missing input validation\u003c/p\u003e \u003cp\u003e• Integer overflow\u003c/p\u003e \u003cp\u003e• Incorrect state update\u003c/p\u003e \u003cp\u003e• Access control bypass\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eConsensus\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eProtocol-level faults\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e• Byzantine node behaviour\u003c/p\u003e \u003cp\u003e• Invalid block proposal\u003c/p\u003e \u003cp\u003e• Double spending\u003c/p\u003e \u003cp\u003e• Equivocation\u003c/p\u003e \u003cp\u003e• Fork induction\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eNetwork\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eCommunication disruptions\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e• Message delay\u003c/p\u003e \u003cp\u003e• Packet loss\u003c/p\u003e \u003cp\u003e• Node disconnection\u003c/p\u003e \u003cp\u003e• Partition injection\u003c/p\u003e \u003cp\u003e• Broadcast suppression\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/table\u003e\u003c/div\u003e\u003cp\u003e\u003c/p\u003e\u003ch2\u003e4.3 Fault Propagation Analysis\u003c/h2\u003e\u003cp\u003eThe propagation analysis module distinguishes this framework from prior single-layer approaches by explicitly tracking the paths through which a fault in one-layer triggers secondary effects in others. Rather than recording only whether a fault leads to system failure, the framework instruments each layer boundary to capture state transitions as fault effects move from one component to the next. A representative propagation chain illustrates this mechanism. A re-entrancy vulnerability at the application layer generates a sequence of malformed transactions. These transactions enter the network layer as broadcast messages and consume propagation bandwidth. Upon reaching the consensus layer, the malformed inputs stress block validation logic, increasing the probability of invalid block proposals and fork creation. Conversely, a network-layer partition that delays block propagation desynchronises node state, which the consensus layer interprets as competing valid chains, inducing a fork that subsequently causes the application layer to receive inconsistent ledger state for contract execution [4]. The framework records these propagation sequences as directed fault paths, capturing the originating fault type, the layer boundary crossed, the secondary effect triggered, and the resulting metric impact at each stage. This structured recording enables post-experiment analysis of fault amplification ratios, reflecting how a localised fault expands into broader system degradation, and helps identify inter-layer dependencies with the highest vulnerability concentration.\u003c/p\u003e\u003cp\u003e \u003c/p\u003e\u003ch2\u003e4.4 Experimental Workflow\u003c/h2\u003e\u003cp\u003eThe experimental process follows a five-stage structured sequence designed to ensure systematic coverage of fault scenarios and reproducibility of results. In the first stage, the framework initialises a simulated blockchain network with a configurable number of nodes, establishing a stable baseline under fault-free conditions against which degraded performance is measured. In the second stage, the evaluator selects the target layer, fault type, and injection parameters through the fault injection engine interface. In the third stage, faults are injected during live transaction execution or block validation, depending on the target layer, ensuring that fault effects interact with active system behaviour rather than idle state. In the fourth stage, the system executes under controlled fault conditions while the monitoring engine continuously collects the four primary metrics, latency, throughput, fork rate, and error rate, at configurable sampling intervals. In the fifth stage, the collected data is analysed to extract fault propagation paths, quantify performance degradation relative to the baseline, and compare single-layer with multi-layer fault scenarios. All experiments are repeated across three injection modes: isolated single-layer faults, simultaneous multi-layer faults, and sequential fault injection, where faults are introduced in a defined order to simulate realistic compounding failure progressions.\u003c/p\u003e\u003ch2\u003e4.5 Evaluation Metrics\u003c/h2\u003e\u003cp\u003eFour metrics are employed to quantify the impact of injected faults on system behaviour. Transaction confirmation latency measures the elapsed time from transaction submission to permanent ledger inclusion, capturing the cumulative delay introduced by fault-induced processing overhead at each layer. Throughput measures the number of transactions successfully processed per unit time, providing a direct indicator of system capacity degradation under fault load. Fork rate tracks the frequency at which competing chain branches emerge during consensus execution, reflecting how fault conditions affect the stability of distributed agreement. Error rate records the proportion of transactions that fail validation or are rejected during execution, capturing the direct impact of application and consensus layer faults on correctness.\u003c/p\u003e\u003cp\u003eTable III\u003c/p\u003e\u003cp\u003e \u003c/p\u003e\u003cdiv class=\"gridtable\"\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003ctable id=\"Tabb\" border=\"1\"\u003e \u003ccolgroup cols=\"4\"\u003e \u003c/colgroup\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colspan=\"4\"\u003e \u003cp\u003eEvaluation metrics, measurement methods, and primary fault drivers.\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003ctr\u003e \u003cth align=\"left\"\u003e \u003cp\u003eMetric\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eUnit\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eMeasurement method\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003ePrimary fault driver\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eLatency\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eMilliseconds (ms)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eTime from tx submission to ledger inclusion, averaged over 100 tx samples\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNetwork delay; Consensus overhead\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eThroughput\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eTx / second (TPS)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eCount of successfully committed transactions per 60-second window\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eMulti-layer faults; Packet loss\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eFork rate\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eForks / 100 blocks\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eCount of chain splits per 100 produced blocks across all nodes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eByzantine nodes; Network partition\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eError rate\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e% of total tx\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eRatio of rejected or failed transactions to total submitted transactions\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eContract faults; State corruption\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/table\u003e\u003c/div\u003e\u003cp\u003e\u003c/p\u003e\u003cp\u003e \u003c/p\u003e "},{"header":"EXPERIMENTAL EVALUATION AND RESULTS","content":"\u003cp\u003e\u003cb\u003e5.1 Experimental Setup\u003c/b\u003e \u003c/p\u003e\u003cp\u003eThe proposed framework was evaluated in a simulated blockchain environment comprising 10 peer nodes, configured to approximate a realistic distributed deployment. The simulation modelled interactions across all three architectural layers, application, consensus, and network, under eight distinct fault scenarios ranging from isolated single-layer faults to simultaneous injection across all three layers. The consensus mechanism used in the evaluation was a BFT-based protocol, consistent with consortium blockchain deployments where Byzantine fault tolerance is a primary reliability requirement [4]. Each experiment was executed over a fixed 300-second window with a constant transaction submission rate of 150 transactions per second. Reported results represent averages over five independent runs to account for non-deterministic network behaviour. Baseline measurements were collected under fault-free conditions prior to each injection run, providing a stable reference for quantifying performance degradation.\u003c/p\u003e\u003ch2\u003e5.2 Impact on Transaction Latency\u003c/h2\u003e\u003cp\u003eExperimental results showed a clear and monotonic increase in transaction confirmation latency as fault scope expanded from single-layer to multi-layer conditions. Under fault-free baseline conditions, average confirmation latency was 210 ms. Single-layer application faults increased this to 310 ms, while isolated network-layer faults produced the highest single-layer latency at 430 ms, reflecting the direct impact of message delays on block propagation timing. Cross-layer combinations produced substantially greater degradation. Simultaneous application and network faults resulted in an average latency of 720 ms, and the three-layer scenario, with faults active across all layers simultaneously, produced a peak latency of 1240 ms, representing a 490% increase over baseline. This amplification indicates that cross-layer fault interactions do not combine linearly; instead, they compound through inter-layer dependencies, leading to repeated validation attempts and accumulation of unresolved state across components.\u003c/p\u003e\u003cp\u003e \u003c/p\u003e\u003ch2\u003e5.3 Impact on Throughput\u003c/h2\u003e\u003cp\u003eSystem throughput exhibited consistent degradation as fault complexity increased. Baseline throughput under fault-free conditions was 142 transactions per second. Isolated single-layer faults reduced throughput moderately. Application-layer faults alone yielded 118 TPS, while network-only faults reduced throughput to 96 TPS as packet loss introduced retransmission overhead and delayed block delivery. The most severe degradation occurred under multi-layer conditions. Simultaneous consensus and network faults reduced throughput to 52 TPS, and the three-layer scenario produced a further reduction to 28 TPS, representing an 80.3% decline from baseline. This collapse reflects the compounding effect in which invalid transactions generated at the application layer consume consensus validation resources, while concurrent network disruptions delay the propagation of even valid blocks [3].\u003c/p\u003e\u003cp\u003e \u003c/p\u003e\u003ch2\u003e5.4 Fork Rate and Error Rate Behaviour\u003c/h2\u003e\u003cp\u003eFork rate and error rate results provide the clearest evidence of cross-layer fault amplification. Under baseline conditions, the fork rate was 0.4 forks per 100 blocks, representing the natural variance of the BFT consensus mechanism. Network-only faults increased this to 3.6, as delayed block propagation caused nodes to independently validate competing chain heads.\u003c/p\u003e\u003cp\u003eThe combination of consensus and network faults produced the most severe fork behaviour, yielding 8.4 forks per 100 blocks, more than double the network-only value, confirming that Byzantine node behaviour and propagation delays interact to destabilise distributed agreement [13]. Under three-layer fault conditions, the fork rate reached 12.7 and the error rate reached 14.3%, the highest values observed across all scenarios. These results show that single-layer analysis cannot capture the extent of degradation produced by concurrent multi-layer faults, as the amplification emerges through inter-layer interaction.\u003c/p\u003e\u003cp\u003e \u003c/p\u003e\u003ch2\u003e5.5 Fault Propagation Patterns\u003c/h2\u003e\u003cp\u003eAnalysis of recorded propagation paths revealed consistent and directional fault propagation behaviour across all multi-layer scenarios. Application-layer faults propagated upward into the consensus layer in cases where malformed transactions were generated. Invalid state updates increased block rejection rates by an average of 34% compared to consensus-only fault baselines. Network-layer faults propagated into the consensus layer by inducing node desynchronisation. In 78% of network fault runs, propagation delays of 400 ms or more caused at least one fork event within the first 60 seconds of execution. Consensus-layer faults, in turn, propagated downward to the application layer by causing nodes to reject valid transactions during fork resolution periods, reducing effective application-layer throughput even in the absence of direct application-layer faults. These bidirectional propagation patterns indicate that blockchain layers are not only logically coupled but also operationally entangled, a property that single-layer fault injection frameworks cannot capture.\u003c/p\u003e\u003ch2\u003e5.6 Comparative Analysis: Cross-Layer vs. Single-Layer Approaches\u003c/h2\u003e\u003cp\u003eA direct comparison between single-layer and cross-layer fault injection outcomes confirms the superior diagnostic capability of the proposed framework. Across all metrics, single-layer fault injection consistently underestimates actual system degradation. The maximum latency observed under any single-layer scenario was 430 ms, whereas the equivalent cross-layer scenario reached 1240 ms, representing a 188% underestimation. Single-layer throughput degradation reached a minimum of 96 TPS, while the cross-layer minimum was 28 TPS, a gap of 70.8%. Fork rates under single-layer conditions peaked at 3.6, whereas the cross-layer peak was 12.7, more than three times higher. These results show that evaluating blockchain resilience through isolated, layer-specific fault injection provides an incomplete and overly optimistic view of system vulnerability.\u003c/p\u003e\u003cp\u003eTable IV\u003c/p\u003e\u003cp\u003e \u003c/p\u003e\u003cdiv class=\"gridtable\"\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"char\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"char\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"char\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"char\" class=\"colspec\"\u003e\u003c/div\u003e\u003cdiv align=\"left\" class=\"colspec\"\u003e\u003c/div\u003e\u003ctable id=\"Tabc\" border=\"1\"\u003e \u003ccolgroup cols=\"6\"\u003e \u003c/colgroup\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colspan=\"6\"\u003e \u003cp\u003eSummary of experimental results across all fault scenarios\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003ctr\u003e \u003cth align=\"left\"\u003e \u003cp\u003eFault scenario\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eLatency (ms)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eThroughput (TPS)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eFork rate (/100 blk)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eError rate (%)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\"\u003e \u003cp\u003eSeverity\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cem\u003eBaseline (no fault)\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e210\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e142\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e0.4\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e1.2\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e—\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eApplication only\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e310\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e118\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e0.8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e4.8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eLow\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eConsensus only\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e380\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e104\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e2.1\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e3.1\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eLow\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eNetwork only\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e430\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e96\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e3.6\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e2.4\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eModerate\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eApp + Consensus\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e610\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e71\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e4.2\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e8.6\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eModerate\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eApp + Network\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e720\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e63\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e5.8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e7.2\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eHigh\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eConsensus + Network\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e850\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e52\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e8.4\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e6.1\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003eHigh\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eAll three layers\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e\u003cb\u003e1240\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e\u003cb\u003e28\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e\u003cb\u003e12.7\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\"\u003e \u003cp\u003e\u003cb\u003e14.3\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\"\u003e \u003cp\u003e\u003cb\u003eCritical\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/table\u003e\u003c/div\u003e"},{"header":"DISCUSSION","content":" \u003cp\u003eThe experimental results show that fault interactions across blockchain layers do not combine additively but amplify multiplicatively, at a level that cannot be predicted through linear superposition of individual fault effects. This non-linear behaviour follows from the operational coupling between layers. Invalid transactions generated at the application layer enter the consensus pipeline as valid processing inputs, consuming validation resources and increasing block rejection rates. At the same time, network disruptions delay the propagation of both valid and invalid blocks, extending the window in which unsynchronised node states can be exploited [4]. The combined effect produces degradation that differs from single-layer scenarios not only in magnitude but also in behaviour. This observation highlights a critical limitation in fault-tolerant blockchain architectures. BFT consensus protocols are designed to tolerate up to one-third of nodes behaving arbitrarily, but this guarantee assumes bounded network delay and well-formed application-layer inputs. When network delays exceed propagation thresholds and application-layer faults increase invalid transaction volume, these assumptions no longer hold in practice, even without exceeding the Byzantine node threshold [5]. In domains such as finance and healthcare, where consensus failures carry significant consequences, this represents a risk that is not visible under single-layer evaluation. The limitations of single-layer fault analysis follow directly from this behaviour. Studies that evaluate smart contract vulnerabilities without considering concurrent consensus and network conditions cannot capture how invalid transactions affect consensus stability [2]. Similarly, network-level analyses conducted without application-layer stress do not reflect how propagation delays interact with transaction volume to induce forks. The results obtained here indicate that this gap leads to consistent underestimation of system degradation across all measured metrics. These findings have practical implications for system design and testing. Fault injection strategies should include simultaneous multi-layer fault scenarios as a standard evaluation component. The observation that network delays exceeding 400 ms triggered fork events in 78% of runs provides a useful reference point for configuring network parameters and timeout thresholds. The observed bidirectional propagation, where application-layer faults degrade consensus performance and consensus instability reduces application-layer throughput, suggests that resilience mechanisms should be designed across layers rather than within isolated components. The evaluation was conducted in a simulated 10-node environment using a BFT consensus mechanism, which is sufficient to demonstrate cross-layer effects, although validation across larger deployments and alternative consensus protocols such as PoW and PoS remains an open direction.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e"},{"header":"CONCLUSION AND FUTURE WORK","content":"\u003cp\u003e \u003c/p\u003e\u003cp\u003eThis paper presents a cross-layer fault injection framework for evaluating the end-to-end resilience of blockchain systems. The framework introduces controlled faults across the application, consensus, and network layers simultaneously, enabling systematic analysis of inter-layer fault propagation and its cumulative impact on system behaviour. Experimental results show that cross-layer fault conditions lead to significantly greater performance degradation than single-layer faults in isolation, with a 490% increase in confirmation latency, an 80.3% reduction in throughput, a fork rate of 12.7 per 100 blocks, and an error rate of 14.3% under three-layer fault conditions. These results indicate that single-layer fault analysis underestimates system vulnerability, as amplification effects from inter-layer interactions are not captured in isolated evaluations [6]. The findings suggest that blockchain fault tolerance guarantees, while theoretically sound, degrade under concurrent multi-layer failures. This has implications for how blockchain systems are tested and prepared for deployment in reliability-critical domains. The proposed framework provides a reproducible and configurable basis for conducting such evaluations across different blockchain configurations and fault scenarios. Several directions remain for future work. Extending the framework to larger node counts and public blockchain platforms would help validate the observed propagation behaviour under real-world conditions. Incorporating additional consensus mechanisms, particularly PoW and PoS variants, would improve the generalisability of the results. Integrating machine learning-based fault injection strategies could support more adaptive exploration of complex fault spaces beyond manually defined scenarios [12]. Finally, coupling the framework with automated recovery mechanisms would enable evaluation not only of how blockchain systems degrade under fault conditions but also how effectively they recover.\u003c/p\u003e"},{"header":"Declarations","content":"\u003cp\u003e \u003cstrong\u003eEthical Approval\u003c/strong\u003e \u003cp\u003eThis manuscript does not involve studies with human participants, human data, human tissue, or animals. No ethical approval was required.\u003c/p\u003e \u003c/p\u003e \u003cp\u003e \u003cstrong\u003eConflict of Interest\u003c/strong\u003e \u003cp\u003eThe author declares no conflict of interest related to the content of this article.\u003c/p\u003e \u003c/p\u003e\u003cp\u003e \u003ch2\u003eUse of AI Assistance\u003c/h2\u003e \u003cp\u003eAI-assisted tools were used only for formatting and minor language refinement. All technical content, including the framework design, analysis, and conclusions, is the author\u0026rsquo;s original work, and the author assumes full responsibility for the accuracy and integrity of the manuscript.\u003c/p\u003e \u003c/p\u003e\u003ch2\u003eFunding\u003c/h2\u003e \u003cp\u003eThis research received no external funding.\u003c/p\u003e\u003ch2\u003eAuthor Contributions\u003c/h2\u003e \u003cp\u003eAneesh Senthil contributed to the conceptualisation of the study, literature review, design of the cross-layer fault injection framework, experimental analysis, and preparation of the manuscript.\u003c/p\u003e\u003ch2\u003eAcknowledgement\u003c/h2\u003e \u003cp\u003eThe author acknowledges the academic support and guidance received during the development of this work.\u003c/p\u003e\u003ch2\u003eAvailability of Data and Materials\u003c/h2\u003e \u003cp\u003eThe findings of this study derive from a simulated evaluation framework. No external datasets were used or generated during this work.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n\u003cli\u003eZhang, X., Chen, J., Li, Y., 2020. Using fault injection to assess blockchain systems. arXiv preprint arXiv:2006.11597.\u003c/li\u003e\n\u003cli\u003eAtzei, N., Bartoletti, M., Cimoli, T., 2017. A survey of attacks on Ethereum smart contracts. Proc. POST, 164\u0026ndash;186. doi:10.1007/978-3-662-54455-6_8.\u003c/li\u003e\n\u003cli\u003eCroman, K., et al., 2016. On scaling decentralized blockchains. Proc. FC, 106\u0026ndash;125. doi:10.1007/978-3-662-53357-4_8.\u003c/li\u003e\n\u003cli\u003eCastro, M., Liskov, B., 1999. Practical Byzantine fault tolerance. Proc. OSDI, 173\u0026ndash;186.\u003c/li\u003e\n\u003cli\u003eLiu, Y., Xu, X., Zheng, Z., 2024. Fault tolerance testing for consortium blockchain systems. Future Generation Computer Systems.\u003c/li\u003e\n\u003cli\u003eArlat, J., Costes, A., Crouzet, Y., Laprie, J., Powell, D., 1990. Fault injection for dependability validation. IEEE Trans. Software Engineering 16 (2), 166\u0026ndash;182. doi:10.1109/32.44383.\u003c/li\u003e\n\u003cli\u003eNakamoto, S., 2008. Bitcoin: A peer-to-peer electronic cash system.\u003c/li\u003e\n\u003cli\u003eLuu, L., et al., 2016. Making smart contracts smarter. Proc. CCS, 254\u0026ndash;269. doi:10.1145/2976749.2978309.\u003c/li\u003e\n\u003cli\u003eWood, G., 2014. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Yellow Paper.\u003c/li\u003e\n\u003cli\u003eKoopman, P., DeVale, J., 1999. Comparing robustness of POSIX systems. Proc. FTCS, 30\u0026ndash;37. doi:10.1109/FTCS.1999.781040.\u003c/li\u003e\n\u003cli\u003eSwan, M., 2015. Blockchain: Blueprint for a new economy. O\u0026rsquo;Reilly Media.\u003c/li\u003e\n\u003cli\u003eChristidis, K., Devetsikiotis, M., 2016. Blockchains and smart contracts for IoT. IEEE Access 4, 2292\u0026ndash;2303. doi:10.1109/ACCESS.2016.2566339.\u003c/li\u003e\n\u003cli\u003eEyal, I., Sirer, E.G., 2014. Majority is not enough. Proc. FC, 436\u0026ndash;454. doi:10.1007/978-3-662-45472-5_28.\u003c/li\u003e\n\u003cli\u003eAvizienis, A., et al., 2004. Basic concepts and taxonomy. IEEE Trans. Dependable Secure Computing 1 (1), 11\u0026ndash;33. doi:10.1109/TDSC.2004.2.\u003c/li\u003e\n\u003cli\u003eDinh, D., et al., 2018. Untangling blockchain. IEEE Trans. Knowledge Data Engineering 30 (7), 1366\u0026ndash;1385. doi:10.1109/TKDE.2017.2781227.\u003c/li\u003e\n\u003cli\u003eJayabalasamy, G., Pujol, C., Bhaskaran, K.L., 2024. Application of graph theory for blockchain technologies. Electronics. doi:10.3390/electronics13082787.\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":true,"hideJournal":true,"highlight":"","institution":"Vellore Institute of Technology University","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true},"keywords":"Blockchain Systems, Fault Injection Testing, Cross-Layer Analysis, Smart Contract Vulnerabilities, Consensus Protocols, Network Fault Simulation, Cascading Failures","lastPublishedDoi":"10.21203/rs.3.rs-9372666/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-9372666/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eBlockchain systems underpin a growing class of decentralized applications where data integrity, fault tolerance, and consensus reliability are critical operational requirements. Despite their architectural strengths, real-world blockchain deployments remain susceptible to complex failure modes that span multiple system layers simultaneously. Existing reliability studies predominantly examine faults in isolation \u0026mdash; targeting either smart contract logic, consensus protocol behaviour, or network communication \u0026mdash; without accounting for the interdependencies that exist across these layers [14]. This narrow scope leaves a critical gap: cascading failures that originate in one layer and propagate through others remain poorly understood and systematically underexplored. This work addresses that gap by proposing a cross-layer fault injection framework that introduces controlled, reproducible faults across the application, consensus, and network layers within a unified simulation environment. The framework incorporates a fault propagation methodology that traces how localised faults amplify into system-wide degradation across layer boundaries. Evaluation across eight fault scenarios \u0026mdash; ranging from isolated single-layer faults to simultaneous three-layer injection \u0026mdash; produced measurable and consistent results. Cross-layer fault conditions increased transaction confirmation latency by 490% over baseline, reduced throughput by 80.3%, raised the fork rate to 12.7 per 100 blocks, and produced an error rate of 14.3%. These results demonstrate that single-layer fault analysis underestimates true system vulnerability by margins exceeding 70% across key performance metrics. The findings establish that holistic multi-layer fault analysis reveals vulnerability classes that single-layer methods cannot detect, and that the proposed framework provides a rigorous and reproducible foundation for evaluating end-to-end blockchain resilience.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003e \u003c/p\u003e","manuscriptTitle":"A Cross-Layer Fault Injection Framework for Cascading Failure Analysis in Blockchain Systems","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2026-04-13 03:16:01","doi":"10.21203/rs.3.rs-9372666/v1","editorialEvents":[{"type":"communityComments","content":0}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"researchsquare","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":true,"externalIdentity":"","sideBox":"","snPcode":"","submissionUrl":"/submission","title":"Research Square","twitterHandle":"researchsquare","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"","reportingPortfolio":"","inReviewEnabled":false,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"e67b4b6b-1fdb-4798-9d88-396f0f084e04","owner":[],"postedDate":"April 13th, 2026","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"posted","subjectAreas":[{"id":66045233,"name":"Theoretical Computer Science"}],"tags":[],"updatedAt":"2026-04-13T03:16:01+00:00","versionOfRecord":[],"versionCreatedAt":"2026-04-13 03:16:01","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-9372666","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-9372666","identity":"rs-9372666","version":["v1"]},"buildId":"XKTyCvWXoU3ODBz1xrDgd","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}