PaperlayerView exact revision on arXiv

Source-linked AI summary

From Network Intrusion Detection to Blockchain-Backed Endpoint Detection and Response: Mapping the Landscape of Decentralized Detection-and-Response Architectures

Yahya Shahsavari, Sara Rouhani, Kaiwen Zhang

arXiv:2610.01872v1cs.CRcs.AIcs.NI

TL;DR

Existing reviews overlook modern EDR/XDR architectures and conflate blockchain’s distinct functional roles. This SoK proposes a three-axis taxonomy and synthesizes the literature to examine the gap in blockchain-backed endpoint response. It finds no surveyed system with a genuine per-endpoint blockchain-anchored R3 response loop and outlines a research agenda centered on hybrid on-chain/off-chain architectures.

  • Problem

    Existing reviews overlook the shift toward EDR/XDR and conflate blockchain’s distinct functional roles, while blockchain-enabled EDR remains remarkably scarce.

    Source: §I · pp. 1–2

  • Method

    The SoK uses a three-axis taxonomy to systematize detection-system class, blockchain functional role, and response-automation maturity.

    Source: §I · p. 2

  • Results

    No surveyed system reaches R3 with a genuine per-endpoint blockchain-anchored response loop; the closest analogue is policy-oriented rather than endpoint-telemetry-oriented.

    Source: §IV · p. 4, B. Where Blockchain Appears Adjacent… · p. 7

  • Takeaways & Limitations

    The research agenda prioritizes hybrid on-chain/off-chain response architectures and post-quantum-agile cryptographic layers.

    Source: §X · p. 11

    The surveyed literature contains no genuine per-endpoint blockchain-anchored R3 response loop.

    Source: §IV · p. 4

Abstract

from arXiv · show

While the literature on blockchain-assisted intrusion detection and prevention systems (IDS/IPS) for Internet of Things (IoT) and Industrial Internet of Things (IIoT) networks is mature, existing systematic reviews suffer from two critical limitations: they overlook the structural shift toward modern Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) architectures, and they conflate blockchain's distinct functional roles into a single monolithic category. This Systematization of Knowledge (SoK) addresses these gaps by proposing a three-axis taxonomy that classifies proposals by detection-system class (NIDS, HIDS, EDR/XDR), blockchain functional role, and response-automation maturity. Synthesizing research published in high-impact venues between 2019 and 2026, we provide a rigorous gap analysis exposing why a genuine per-endpoint blockchain-anchored response loop remains nearly nonexistent due to latency, deployment, and community mismatches. Furthermore, we evaluate structural, cross-cutting challenges persisting across the literature, including consensus latency on constrained devices, post-quantum cryptographic vulnerability, smart-contract attack surfaces, and the adversarial vulnerability of evolving LLM-based detection engines. Finally, we outline a comprehensive research agenda centered on hybrid on-chain/off-chain orchestration to bridge the gap between decentralized trust and rapid response automation.

I. INTRODUCTION

The SoK argues that existing blockchain-security reviews miss the shift from mature IoT IDS/IPS work toward EDR/XDR and group systems that use blockchain for distinct architectural roles. It responds with a broader systems perspective, a structured synthesis, and an analysis of response automation and cross-cutting problems.

Observation 1: Existing literature is heavily concentrated on IDS/IPS, whereas blockchain-enabled Endpoint EDR remains largely unexplored.

  • Existing blockchain-enabled cyber defense research is concentrated on network- and IoT-device-level IDS/IPS, while comparable blockchain-enabled EDR investigations are scarce.The authors frame this asymmetry as a systematizable finding that motivates examining contemporary detection and response beyond IDS alone.Source: §I · pp. 1–2

Observation 2: ”Blockchain-based IDS” conflates distinct functional roles.

  • Surveys often group systems by application domain or platform, obscuring that blockchain can provide logging, decentralized trust, incentives, or federated-learning integrity.These roles can support different comparisons and have different levels of maturity.Source: §I · p. 2

Observation 3: Detection dominates; prevention and response remain shallow.

  • Most blockchain-enabled security systems stop after generating alerts; comparatively few provide explicit prevention or automated response [27].The paper motivates examining the full detection, prevention, and response lifecycle.Source: §I · p. 2

Contributions

  • The SoK introduces a three-axis taxonomy, synthesizes high-impact-venue IDS/IPS and EDR research, and analyzes recurring cross-cutting problems.Its research agenda targets blockchain-backed EDR/XDR with automated, smart-contract-driven response in the taxonomy’s most underexplored cell.Source: §I · p. 2

II. BACKGROUND

The background distinguishes detection-and-response system classes by their monitoring scope and response capabilities, then describes blockchain primitives used in these architectures. It links four primitives to functional roles in the taxonomy and treats smart contracts as a cross-cutting mechanism for response automation.

A. Detection-and-Response System Classes

  • NIDS monitors network traffic, HIDS monitors one host’s internal state, and IPS adds active mitigation to detection.The surveyed IDS/IPS literature remains detection-oriented, with comparatively few proposals providing genuine prevention functionality [27].Source: A. Detection-and-Response System Classes · pp. 2–3
  • EDR emphasizes continuous endpoint telemetry, behavioral analytics, automated investigation, and orchestrated response; XDR correlates telemetry across endpoints and other security controls.The surveyed blockchain literature gives XDR little attention and mostly focuses on standalone IDS or EDR architectures.Source: A. Detection-and-Response System Classes · p. 3

B. Blockchain Primitives Relevant to Detection-and-Response Design

  • Blockchain primitives include immutable ledgers for tamper-evident alert records, consensus for decentralized trust, smart contracts for policy enforcement, and incentives for honest participation.Federated-learning integrity assurance uses blockchain to make model-update exchanges verifiable and tamper-resistant [25].Source: B. Blockchain Primitives Relevant to… · p. 3
  • Four primitives map to the taxonomy’s logging, trust, incentive, and FL-integrity roles, while smart contracts implement response automation across roles.A contract may operationalize logging, consensus, incentive payout, or FL-update verification, depending on the role it supports.Source: B. Blockchain Primitives Relevant to… · p. 3

III. SYSTEMATIZATION METHODOLOGY

The paper systematizes existing knowledge rather than proposing a new detection algorithm, targeting high-impact venues and recent relevant preprints. Its search combines blockchain and detection-response terms, and Fig. 1 depicts representative systems across taxonomy axes.

III. SYSTEMATIZATION METHODOLOGY

  • The paper follows SoK methodology to expose structure, redundancy, and gaps that are difficult to see when papers are read individually.It does not propose a new detection algorithm.Source: §III · p. 3

A. Scope and Search Strategy

  • The search targeted high-impact venues and supplemented them with recent arXiv preprints for 2025–2026 work.Search terms combined blockchain, distributed ledger, or smart contract with intrusion detection, intrusion prevention, EDR, endpoint detection and response, federated learning, or IDS.Source: A. Scope and Search Strategy · pp. 3–4
  • Fig. 1 positions representative systems by detection-system class and response-automation maturity, with color or fill loosely indicating dominant blockchain role.Its dashed region marks the largely unoccupied EDR/XDR × R2/R3 cell.Source: Figure 1 · p. 4

B. Inclusion Criteria

The inclusion criteria select architectures in which blockchain has a structural role and the primary function concerns detection, prevention, or endpoint/extended response. The taxonomy organizes systems across detection class, blockchain role, and response maturity, revealing a largely unoccupied endpoint-response intersection.

B. Inclusion Criteria

  • Included work must give blockchain or a distributed ledger a structural role in a detection, prevention, or endpoint/extended response architecture.Pure blockchain-security work is included only when directly relevant to response automation.Source: B. Inclusion Criteria · p. 4
  • A small set of non-blockchain reference systems anchors detection-class and response-maturity baselines, but is excluded from blockchain-role statistics and completeness claims.These references address what R2/R3 looks like without blockchain, not the maturity of blockchain-EDR.Source: B. Inclusion Criteria · p. 4

C. Why a Taxonomy Rather Than a Chronological Catalogue

  • Organizing by blockchain function rather than chronology or application domain helps distinguish systems whose domains match but whose blockchain roles differ.The role determines which open problems apply to a system.Source: C. Why a Taxonomy Rather Than a… · p. 4

IV. A THREE-AXIS TAXONOMY

  • The taxonomy classifies systems by detection class, blockchain role, and response maturity; no surveyed system reaches R3 with a genuine per-endpoint blockchain-anchored response loop.Trust/consensus and FL-integrity roles dominate NIDS, while response automation rarely exceeds R1–R2 and EDR systems are almost entirely without blockchain integration.Source: §IV · p. 4

V. BLOCKCHAIN-BASED NETWORK AND HOST IDS/IPS

The section groups blockchain-based network and host IDS/IPS by blockchain function rather than application domain. It emphasizes trust through consensus and federated-learning integrity, while showing consensus overhead and resource constraints as recurring design pressures.

A. Trust and Consensus for Collaborative Detection

  • Consensus replaces a trusted central aggregator among mutually distrustful detection nodes, while detection remains more common than prevention or response, [27].The same coordination approach trades throughput for the integrity guarantees decentralization provides.Source: A. Trust and Consensus for… · p. 5
  • PoFQ targets decentralized federated-learning threat hunting, while multi-proof-of-work schemes seek lower resource use during AIoT anomaly-analysis transactions,.These designs respond to consensus coordination overhead, which trades throughput for decentralization’s integrity guarantees.Source: A. Trust and Consensus for… · p. 5

B. Federated-Learning Integrity Assurance

  • Blockchain paired with federated learning secures model-update exchanges while keeping raw data local to each node.Examples include vehicular edge computing, UAV networks, and IIoT anomaly detection [25].Source: B. Federated-Learning Integrity… · p. 5
  • In IIoT, blockchain-FL records model updates and anomaly scores tamper-resistently while keeping raw telemetry at the edge [25].A 2026 resource-constrained industrial IoT prevention framework reports scalability and resource-utilization overhead as remaining obstacles.Source: B. Federated-Learning Integrity… · pp. 5–6

C. Evidentiary and Audit Logging

The section distinguishes audit logging, incentives, and active prevention as separate uses of blockchain in network and host security. Audit logging is comparatively straightforward to retrofit, whereas incentives remain immature and prevention examples include DDoS mitigation.

C. Evidentiary and Audit Logging

  • Detection metadata and encrypted feature vectors can be stored in blocks to make intrusion alerts immutable and traceable.This role needs no distributed-training infrastructure and may suit industrial or embedded settings where full federated learning is impractical.Source: C. Evidentiary and Audit Logging · p. 6

D. Incentive Mechanisms

  • CyberNFTs frames intrusion detection as a reward-driven decentralized task, but incentive mechanisms remain the least mature functional role.The survey found no high-impact-venue example combining incentives with a deployed, evaluated detection pipeline at the scale of the FL-integrity work.Source: D. Incentive Mechanisms · p. 6

E. Active Prevention and DDoS-Specific Mitigation

  • DDoS prevention examples include optimized deep-learning approaches, link-flooding detection and mitigation, and threshold-based smart contracts that bound validator-layer exposure,.The cited DoS survey instead treats the blockchain itself as the asset under attack [54].Source: E. Active Prevention and DDoS-Specific… · p. 6

F. AI- and LLM-Based Detection Engines Within Blockchain Architectures

The section traces AI and LLM detection engines within blockchain architectures, then contrasts those network-focused systems with the sparse overlap between blockchain and EDR. The closest examples remain distinct from a per-endpoint runtime detection-and-response loop.

F. AI- and LLM-Based Detection Engines Within Blockchain Architectures

  • AI and machine-learning detectors cut across blockchain roles, and recent work applies LLMs to network intrusion detection, including zero-shot multi-agent detection [58].The tri-LLM framework uses semantic disagreement and trust-aware aggregation; the paper notes no LLM-based EDR/XDR-class detection engines in the surveyed literature.Source: F. AI- and LLM-Based Detection Engines… · pp. 6–7
  • LQB-IDS combines an LLM-based IoT detector with a post-quantum-secure blockchain and reports detection without labeled training data.The paper identifies it as the closest integrated AI-engine, blockchain, and post-quantum example in the surveyed corpus.Source: F. AI- and LLM-Based Detection Engines… · pp. 6–7
  • Blockchain-for-LLM-security work reverses the primary framing by securing LLM behavior rather than using an LLM plus blockchain to secure a network or endpoint [59],.Source: F. AI- and LLM-Based Detection Engines… · p. 7

A. The State of EDR Research Independent of Blockchain

B. Where Blockchain Appears Adjacent to EDR, but Not Within It

  • An AI, blockchain, and smart-contract compliance framework is the closest blockchain-EDR analogue, but acts on organizational policy rather than endpoint telemetry.It has R3-level closed-loop characteristics but is not benchmarked against endpoint-level detection workloads.Source: B. Where Blockchain Appears Adjacent… · p. 7
  • A blockchain-backed vulnerability-discovery framework evaluated on 500 endpoints is the closest per-endpoint integrity pipeline, but does not implement orchestrated isolation or rollback [62].Its framing is vulnerability discovery, not runtime behavioral detection-and-response.Source: B. Where Blockchain Appears Adjacent… · pp. 7–8

C. Why This Gap Likely Exists

The paper presents latency, deployment models, and research-community separation as hypotheses for the EDR-blockchain gap, not established explanations. It argues that cross-cutting challenges recur across detection classes and that porting existing blockchain-IDS patterns to endpoints requires resolving latency first.

C. Why This Gap Likely Exists

  • EDR may need sub-second containment, while blockchain consensus in surveyed IDS architectures takes seconds at best and constrained IoT systems report scalability and resource overhead.The authors hypothesize that waiting for multi-node consensus may help explain the absence of R3 individual-endpoint response.Source: C. Why This Gap Likely Exists · p. 8
  • Vendor-centralized EDR may offer less incentive for blockchain than multi-stakeholder settings without a central authority.Source: C. Why This Gap Likely Exists · p. 8
  • The surveyed EDR and blockchain-IDS research appears concentrated in different venue communities, with near-total absence of cross-citation.The paper presents this separation as a possible explanation for the gap, not an established cause.Source: C. Why This Gap Likely Exists · p. 8

D. Implications

  • The surveyed open problems recur across functional roles and detection classes, and endpoint architectures cannot simply port dominant FL-integrity or trust-consensus patterns before resolving latency.This motivates the paper’s layered or hybrid architectural direction.Source: §VII · p. 8, D. Implications · p. 8

A. Scalability and Consensus Latency

The surveyed literature faces a recurring consensus-latency and resource-constraint problem, alongside security gaps in cryptography, response contracts, and AI/ML detection engines. These issues constrain automated response and leave important attack surfaces insufficiently addressed.

A. Scalability and Consensus Latency

  • Consensus coordination and limited device resources constrain real-time processing, while R2/R3 responses need consensus within operationally useful windows.Federated learning can add resource demands independently of blockchain overhead, and strong Byzantine-fault-tolerant consensus trades throughput against decentralized integrity.Source: A. Scalability and Consensus Latency · p. 8

B. Post-Quantum Cryptographic Exposure

  • None of the surveyed blockchain-IDS/IPS or EDR-adjacent systems explicitly discusses post-quantum readiness, despite long industrial and vehicular deployment lifecycles.Current blockchain hashing and signatures face threats from quantum algorithms, while constrained-hardware feasibility also matters for IoT deployments.Source: B. Post-Quantum Cryptographic Exposure · pp. 8–9

C. Smart-Contract Attack Surface

  • Automated response contracts add an attack surface that the surveyed IDS/IPS literature largely treats as trusted rather than independently secured.An exploitable contract could weaponize endpoint isolation or traffic blocking; cited mitigations include reentrancy prevention and bytecode obfuscation.Source: C. Smart-Contract Attack Surface · p. 9

D. Adversarial Robustness of the AI Detection Engine

  • Blockchain can immutably record incorrect detector verdicts, and poisoning defenses in federated-learning systems remain a minority practice.A proposed monitoring-and-detection separation is a partial mitigation for targeted and untargeted poisoning.Source: D. Adversarial Robustness of the AI… · p. 9
  • Surveyed LLM-based IDS work, including LQB-IDS, does not evaluate robustness to adversarial inputs targeting the LLM component.Prompt injection and hallucination could lead to traffic or endpoint-behavior misclassification, with failure modes that differ from classical ML detectors.Source: D. Adversarial Robustness of the AI… · p. 9

E. Evaluation Methodology Weaknesses

Evaluation practices make results difficult to compare, and the surveyed systems generally assume one homogeneous ledger despite likely multi-organization deployments. The authors argue that this SoK is timely when it addresses EDR/XDR, cross-cutting challenges, and functional distinctions rather than repeating IoT-IDS surveys.

E. Evaluation Methodology Weaknesses

  • Evaluations often use synthetic or simulated workloads and inconsistent baselines, while high accuracy claims may coexist with substantial real-time processing overhead.The paper calls for common datasets and joint reporting of latency under load, accuracy, and overhead trade-offs.Source: E. Evaluation Methodology Weaknesses · p. 9

F. Interoperability Across Heterogeneous Blockchain Deployments

  • Most surveyed systems assume a single homogeneous blockchain, while multi-organization detection is more likely to involve independently governed ledgers.Interoperability across such ledgers is largely absent from the IDS/IPS/EDR-specific corpus.Source: F. Interoperability Across… · p. 9

VIII. IS THIS SOK TIMELY IN 2026?

  • The authors judge a 2026 SoK timely only with an EDR/XDR-inclusive, function-separated framing, citing the underexplored endpoint intersection and newly connected cross-cutting concerns.They also identify the LLM-detection shift and a functional-role taxonomy as reasons the work differs from a chronological update.Source: §VIII · pp. 9–10

IX. FUTURE RESEARCH DIRECTIONS

The research agenda targets the gaps identified in latency, cryptographic readiness, contract security, and evaluation. Its proposals range from separating fast response from ledger audit to building EDR-appropriate benchmarks.

A. Hybrid On-Chain/Off-Chain Response Architectures

  • Execute containment locally under an EDR-realistic latency budget, then asynchronously commit a tamper-evident action record to the ledger.This separates rapid response from audit and accountability, where consensus latency is more acceptable.Source: A. Hybrid On-Chain/Off-Chain Response… · p. 10

B. Lightweight, EDR-Appropriate Consensus

  • Benchmark consensus protocols against EDR containment windows of sub-second to low-single-digit seconds, using a dedicated benchmark suite.The surveyed literature does not currently provide such an EDR-specific suite.Source: B. Lightweight, EDR-Appropriate… · p. 10

C. Post-Quantum-Ready Detection-and-Response Ledgers

  • Build cryptographic agility—the ability to swap signature and hash primitives without redesigning the ledger—into future blockchain IDS/EDR architectures.The paper recommends drawing on post-quantum blockchain work rather than treating migration as a later problem,,.Source: C. Post-Quantum-Ready… · p. 10

D. Smart-Contract Security as a First-Class Design Concern for Response Automation

  • Threat-model R2/R3 response contracts with rigor comparable to financial smart contracts, including response-specific reentrancy-style analysis.One proposed scenario asks whether a compromised endpoint could trigger false containment against a legitimate node.Source: D. Smart-Contract Security as a… · p. 10

E. Standardized, Latency-Aware Evaluation Benchmarks

  • Use a shared benchmark that jointly reports detection accuracy and end-to-end response latency under realistic device and network constraints.This would make accuracy-overhead trade-offs comparable across papers rather than leaving them implicit.Source: E. Standardized, Latency-Aware… · p. 10

F. Cross-Chain Interoperability for Multi-Stakeholder Detection Consortia

The research agenda extends from cross-chain intelligence sharing to LLM-based EDR and, longer term, XDR. The conclusion frames the field through a three-axis taxonomy and highlights the gap between mature NIDS work and underexamined EDR/XDR integration.

F. Cross-Chain Interoperability for Multi-Stakeholder Detection Consortia

  • Explore interoperability protocols so independently governed detection ledgers can share threat intelligence verifiably without a single shared chain.Examples include separate ledgers for healthcare networks and fleet operators.Source: F. Cross-Chain Interoperability for… · p. 10

G. LLM-Based Detection Engines for Blockchain-Anchored EDR

  • Pair an LLM-based detection core with hybrid on-chain/off-chain response as an unexplored EDR direction, and evaluate prompt-injection robustness.The paper notes that EDR response actions such as host isolation and process termination make manipulated verdicts operationally consequential.Source: G. LLM-Based Detection Engines for… · p. 10

H. Extending Beyond EDR Toward XDR

  • XDR is a longer-horizon direction than nascent EDR-blockchain integration, with added trust-and-consensus complexity across telemetry domains and stakeholders.The proposed architecture separates immediate local containment from asynchronous ledger audit; its optional feedback loop represents an R3 ideal not implemented per endpoint in surveyed systems.Source: H. Extending Beyond EDR Toward XDR · pp. 10–11, Figure 2 · p. 11

X. CONCLUSION

  • The SoK separates detection class, blockchain functional role, and response maturity, finding NIDS integration saturated while EDR/XDR remains substantially unexamined.It identifies latency, deployment-model, and community mismatches alongside quantum, contract, and LLM-engine risks, and prioritizes hybrid response and post-quantum agility.Source: §X · p. 11
Loading 2610.01872v1…