Security Threats and Their Impact on Blockchain Interoperability: Identification and Countermeasures Shawn M. Reynolds, Hassan Reza School of Electrical Engineering and Computer Science University of North Dakota Grand Forks, ND 58201, USA [email protected]; [email protected]
Abstract—Blockchain interoperability enables independent blockchain systems to communicate and exchange assets across heterogeneous networks. A major weakness limiting its effectiveness is the lack of comprehensive security mechanisms. Attacks have already caused hundreds of millions in asset losses, demonstrating the severity of this threat. This paper identifies and counters all known attacks and vulnerabilities facing interoperable blockchain systems. We classify threats into five categories: (1) core blockchain attacks, (2) network attacks, (3) interoperability-specific attacks, (4) social engineering, and (5) code vulnerabilities— particularly in smart contracts. For each threat, we identify effective countermeasures. By cataloging these threats and their solutions, we provide a foundation for designing secure blockchain interoperability solutions. Keywords—blockchain interoperability; security countermeasures; smart contracts; cross-chain attacks
threats;
I. INTRODUCTION Blockchains (BCs) are decentralized, immutable data structures built on distributed database systems. A BC is a sequence of blocks connected by hash pointers; any modification is detectable because hash values would no longer match [4]. Nodes maintain copies of the BC and reach consistency through consensus, ensuring new blocks are appended only when most nodes agree [4]. Smart contracts extend BC functionality through self-executing programs that automate predefined actions [1]. Unfortunately, BCs cannot natively interoperate with one another, drastically limiting their utility. BC interoperability enables different blockchains to communicate, exchange data, and transfer assets [1]. Solutions enabling these interactions are often called bridges [14]. However, building interoperability on existing, heterogeneous BC technology is challenging, and security is among the most pressing concerns before ever considering interoperability. Security threats compound in interoperable systems: vulnerabilities exist at the base BC layer, at the network layer, and in the cross-chain protocols themselves [15]. Attacks have already succeeded against real systems—the Ronin bridge attack ($624M), Poly Network ($611M), and BNB ($566M) illustrate the severity [15]. Despite this, existing research often addresses only one or a few attacks while ignoring others [19]. This paper addresses the gap by performing a comprehensive threat analysis. We identify 38 attacks and vulnerabilities across five categories and provide countermeasures for each. Our contributions are:
• Identify all security threats across five classifications: core BC, Network, Interoperability, Social Engineering, and Vulnerabilities. • Identify countermeasures for every identified threat. The remainder of this paper is organized as follows: Section II reviews related work; Section III presents the security threats; Section IV presents countermeasures; Section V concludes.
II. RELATED WORKS Much work has been done on BC security, but it is scattered across components and attack types. No single work considers all threats and solutions holistically. We surveyed peer-reviewed papers from 2016–2026 addressing security in BCs and BC interoperability. In [2], several consensus attacks are described—Sybil, 51%, Nothing at Stake, and double-spending—but without full solutions. Work in [7] proposes ETH Relay and addresses relay-specific attacks (relay poisoning, incentive attacks) with countermeasures but ignores other threat classes. A comprehensive BC vulnerability taxonomy is introduced in [15], covering many attack categories with countermeasures, but some entries lack detailed impact analysis. In [19], BC security threats are categorized across consensus, network, and application layers with detailed solutions. Work in [23] examines 20 Bitcoin-specific attacks with descriptions, targets, consequences, and countermeasures—a model for thorough threat analysis, though it omits interoperability. In [25], communication protocol vulnerabilities in Algorand, Aptos, Avalanche, Redbelly, and Solana are studied, showing targeted load, transient failure, packet dropping, and stopping attacks. Work in [28] provides mathematical proof showing the effectiveness of a sore loser attack defense for atomic swaps. Social engineering is addressed in [36] (phishing in BC environments) and [37] (address manipulation and homograph attacks in smart contracts). Cross-chain bridge attack detection is the focus of [41], which identifies unrestricted deposit emitting, inconsistent event parsing, and unauthorized unlocking. While these works make important contributions, none provides a unified threat analysis spanning all five categories relevant to BC interoperability. This paper fills that gap.
III. SECURITY THREATS BC interoperability is composed of multiple components, each susceptible to different attacks. We classify threats into five categories: BC attacks (targeting core BC infrastructure), network attacks (abusing communication), interoperability-specific attacks (unique to cross-chain systems), social engineering (targeting
1
users), and vulnerabilities (code and design weaknesses enabling attacks). We focus on threats applicable broadly to interoperable systems, excluding niche or deprecated attacks and privacy-specific threats. A. BC Attacks 51% Attack: An attacker controlling more than 51% of BC nodes or computational power can dominate consensus, enabling illegitimate blocks and further fraud [16]. Detection metrics include a single user mining a disproportionate share of blocks [17]. Sybil Attack: The attacker creates many pseudonymous identities to gain undue consensus influence, enabling denial-ofservice by controlling message routing and reducing authentic node redundancy [20]. Double-Spending: The attacker spends the same cryptocurrency multiple times, often due to transaction conflicts or desynchronization in the lock-and-burn process of cross-chain transactions [16][17]. Block Withholding Attack: A malicious miner submits partial proof-of-work, preventing the pool from receiving rewards while remaining anonymous [19]. Selfish Mining: The attacker hides completed proof-of-work to gain an advantage on the next block, earning unfair rewards and potentially causing forks. Requires approximately 50% of total computational power [17][19]. Fork After Withholding Attack: Combines block withholding and selfish mining so only specific pool members receive increased rewards while honest miners waste resources. [19]. Private Key Leakage: An attacker steals a BC account's private key via network methods, physical node capture, or compromised RPC/notary nodes, gaining full account control and theft of funds [11][16]. Nothing at Stake Attack: The attacker replicates the entire BC history, accumulating stake in their copy, then uses the longer chain to take over—common in naive proof-of-stake BCs [21]. Time-Jacking Attack: The attacker plants fake-timestamped nodes to manipulate miner clocks, enabling alternate chain acceptance and double-spending [23]. Replay Attack: The attacker intercepts and retransmits transaction packets or exploits missing magic value or nonce validation to duplicate transactions across chains. A common consequence is double spending [6][19]. Transaction Malleability: The attacker modifies a transaction's unique ID without invalidating it, enabling double deposits and double withdrawals on exchanges [19][23]. Reentrancy Attack: The attacker exploits a publicly visible smart contract vulnerability by calling it repeatedly. Since contracts are immutable once deployed, the vulnerability cannot be patched [19]. B. Network Attacks Denial-of-Service (DoS/DDoS): Nodes or resources are made unavailable by flooding with invalid transactions. Larger networks with more nodes are more resilient. Bitcoin alone has experienced 142 documented DoS attacks [23]. Botnet: A network of compromised nodes performs attacks on behalf of an attacker, including DoS, eclipse attacks, credential brute-forcing, and unauthorized mining [24].
Packet-Dropping Attack: The attacker causes targeted nodes to drop packets, halting communication. TCP-based BCs (e.g., Algorand, Redbelly) can lose 95% of bandwidth; recovery is slow [25]. Stopping Attack: The attacker shuts down a large fraction of BC nodes—at 90% compromise, throughput approaches zero and transactions stall. Recovery is further hindered by consensus leader selection failures (e.g., Solana) [25]. Eclipse Attack: The attacker surrounds a target node with malicious nodes, isolating it from the legitimate network. Enables privacy loss, resource manipulation, and double-spending. Known to affect relay nodes in interoperable BCs [16][18][19]. Partitioning Attack: Abuses peer management to prevent communication among a set of nodes. Often performed by forcing the download of invalid blocks; closely related to eclipse attacks [13]. Man-in-the-Middle Attack: The attacker intercepts and potentially modifies cross-chain communication using IP, ARP, or DNS spoofing, causing privacy loss and transaction manipulation [24][26]. C. Interoperability Attacks Relay Poisoning Attack: The attacker submits invalid or validbut-fraudulent block headers to a relay to reorganize the chain or approve unauthorized cross-chain transactions [7][18]. Oracle Poisoning: The attacker feeds false exchange rate data to the BC oracle, enabling unfair liquidation of collateral or unauthorized collateral-free unlocking. Risk is highest with singlesource oracles [18]. Goldfinger Attack: A 51%-style attack specifically targeting a BC to destroy it for economic or political gain. Particularly dangerous for new sidechains during bootstrapping due to low initial stake [1][27]. Sore Loser / Lockup Griefing Attack: A participant halts communication mid-transaction, leaving assets locked indefinitely. Nearly impossible to fully prevent due to the distributed nature of BCs [28]. Unrestricted Deposit Emitting: The attacker bypasses asset locking by exploiting unsafe transfer functions in smart contracts, enabling deposits at the destination without a corresponding source lock (e.g., Multichain, Meter.io) [41]. Unauthorized Unlocking: The attacker obtains asset unlock keys through key leakage and unlocks assets without proper sourcechain authorization, enabling double-spending (e.g., Anyswap) [41]. D. Social Engineering Social Engineering: Attackers manipulate users into exposing private keys or credentials through impersonation, pretexting, reverse social engineering, or whaling [35][36]. Phishing: Fake emails, websites, or wallets trick users into surrendering credentials or funds. Techniques include clone sites with lookalike domains, bloating schemes, fake ICOs, and malicious wallet apps [33][35]. Homograph Visual Cognitive Deception: The attacker substitutes visually similar Unicode characters in smart contract code, addresses, or function headers. Success rates of 50% have been demonstrated on hardware wallets [34][37]. E. Vulnerabilities
2
Smart Contract Vulnerabilities: Once deployed, smart contracts are immutable and publicly visible, making any vulnerability permanent and exploitable indefinitely. Risks include unprotected self-destruct functions and business logic flaws, which can lead to theft of funds and other attacks [6][15]. Public Key Cryptography Vulnerabilities: Fault attacks, voltage/clock glitches, and related-key attacks can compromise RSA, ECC, ECDSA, EdDSA, and Schnorr keys, particularly on physical wallet hardware [6][29][30][31][32]. Improper Value Validation: Missing magic value or nonce validation in smart contracts allows replay attacks across chains [6]. Smart Contract Visibility Vulnerability: Functions without access labels default to public, exposing data and allowing unauthorized calls [6]. Weak Randomness: Using block hash, number, or timestamp for randomness is predictable and exploitable (e.g., SmartBillions lottery theft) [6].
Attack 51% Attack Sybil Attack Double-Spending Block Withholding Selfish Mining Fork After Withholding Private Key Leakage Nothing at Stake Time-Jacking Replay Attack Tx Malleability Reentrancy DoS / DDoS Botnet Packet-Dropping Stopping Attack Eclipse Attack Partitioning Man-in-the-Middle Relay Poisoning Oracle Poisoning Goldfinger Sore Loser / Lockup Griefing Unrest. Deposit Emit. Unauthorized Unlock Social Engineering Phishing Homograph Deception Smart Contract Vulns Public Key Crypto Vulns Improper Value Validation Visibility Vulnerability Weak Randomness Tx Order Dependence Asset Counterfeiting Verifier's Dilemma Invalid Consensus Proofs Inconsistent Event Parse
Category BC BC BC BC BC BC BC BC BC BC BC BC Network Network Network Network Network Network Network Interop. Interop. Interop. Interop. Interop. Interop. Social Eng. Social Eng. Social Eng. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab.
Transaction Order Dependence: Higher-fee transactions are prioritized, enabling an attacker to copy and front-run another user's solution to claim rewards [6]. Asset Counterfeiting: Cryptocurrency issued without proper collateralization proof, causing inflation and trust loss. Particularly affects Zcash-based BCs [18]. Verifier's Dilemma: Validator nodes cease verifying transactions due to low perceived risk, high cost, or assumed redundancy, enabling fraudulent transactions [39]. Invalid Consensus Proofs: Attackers submit fake blocks with forged sync committee signatures or replay valid proofs to duplicate transactions. Enables double-spending [40]. Inconsistent Event Parsing: The event parser incorrectly validates malicious cross-chain events or miscounts assets, causing abusable unexpected behavior (e.g., THORChain, pNetwork) [41]. F. Summary Table I summarizes all 38 identified attacks and vulnerabilities, their categories, impacts, and references.
Impact Attacker controls consensus, fraud Consensus disruption, DoS Fraudulent spending Disrupted mining, reward loss Unfair rewards, potential fork Forking, reward theft Account takeover, fund loss BC hijack Double-spending, resource waste Transaction duplication Double-spending, fund theft Financial exploitation Nodes offline, BC halted DoS, eclipse, further attacks Communication halted BC halted, lost transactions Privacy loss, double-spending Eclipse attack Privacy loss, tx manipulation Fraudulent cross-chain txns Fund loss, unfair exchange Fork, double-spending Assets locked indefinitely Double-spending Double-spending Account/fund loss Account/fund loss Tx alteration, fund theft Fund loss, attacks Key/account compromise Replay attacks Unauthorized access Exploitable randomness Reward theft Trust loss, inflation Fraudulent txns Double-spending Unexpected behavior
Refs [15-17] [16][17][20] [16][17] [19] [13][17][19] [13][19] [11][16] [2][21] [8][23] [6][19] [19][23] [19] [13][16][17] [23][24] [25] [25] [16][18][19] [13] [10][24][26] [7][18] [9][18] [1][23][27] [1][28] [41] [41] [19][35-37] [23][33][35] [34][37] [1][6][15] [6][29-32] [6] [6] [6] [6] [15][18] [15][39] [15][40] [15][41]
TABLE I. BC INTEROPERABILITY ATTACKS AND VULNERABILITIES
IV. COUNTERMEASURES We now present countermeasures for each threat, organized by category. Common patterns emerge across categories: monitoring
and detection systems address 11+ threats; validation techniques counter replay, consensus proof, and event parsing attacks; timestamp mechanisms defend against replay, time-jacking, and double-spending; reputation systems deter Sybil, eclipse, and
3
Goldfinger attacks; and code audits eliminate many smart contract vulnerabilities before deployment. A. BC Attack Countermeasures 51% Attack: Increase overall network hash rate; distribute nodes among many unique entities; adopt Proof-of-Stake or Proofof-Authority consensus; increase PoS validator count to reduce bribery opportunities; monitor for suspicious mining patterns [12][16][19][23][42]. Sybil Attack: Use permissioned or hybrid BCs where all participants are known; or implement a reputation system assigning trust scores based on age and behavior, preventing rapid multiaccount creation from gaining consensus power [2][20]. Double-Spending: Combine higher hash rate, transaction validity checks (hash, timestamp, nonce), lock-and-burn asset transfers with post-burn delay, timestamp logging, and notification blocking to prevent repeat offenders [17][23][35][42][43]. Block Withholding: Deploy monitoring with verifiable shares (Stratum protocol); use reputation-based reward reduction; apply revenue distribution adjustments; limit pool participation to trusted users; use zero-knowledge proofs for full proof-of-work commitment [19][23]. Selfish Mining: Optimize block propagation; apply dynamic difficulty adjustment; use protocol upgrades to close known exploits; introduce randomness in fork selection; use unforgeable timestamps to prioritize freshly published blocks [19][23]. Fork After Withholding: Use improved block confirmation to detect competing forks; enhance consensus to reject malicious forks; employ silent timestamps; apply incentive systems rewarding complete proof-of-work [19]. Private Key Leakage: Limit wallet balances; encrypt private keys with password-protected symmetric keys; require multisignature transactions, distributing key storage across separate locations [11]. Nothing at Stake: Apply a checkpoint latch that prevents BC reorganization once a branch reaches a threshold size tied to validator liquidation periods [21]. Time-Jacking: Enforce tighter transaction acceptance time windows; use system time as a fallback; obtain time samples from trusted peers via NTP [23]. Replay Attack: Validate magic values and nonces for all transactions; use unique zero-knowledge-proof-backed locks in atomic swaps; enforce timestamp-based validity windows [6][18][19][24][22]. Transaction Malleability: Implement Segregated Witness (also improves scalability and atomic swap performance); enforce strict signature encoding; modify transaction ID generation to exclude mutable fields; use collisionless hash algorithms [19][23]. Reentrancy: Apply Check-Effects-Interactions pattern; use mutex locks/state variables for synchronization; audit code for recursive call vulnerabilities; implement static/dynamic analysis tools and fuzz testing [15][19]. B. Network Attack Countermeasures DoS/DDoS: Increase peer connections; restrict access to trusted IPs; throttle transaction rates; block known attack patterns; adopt Proof-of-Activity consensus; deploy fast-verification authentication; use ML-based traffic monitoring with isolated containment [11][17][23].
Botnet: Require node authentication; educate users to avoid malicious files and links; monitor for ongoing attack signatures; verify node validity continuously before each transaction [24][5]. Packet-Dropping: Switch to QUIC protocol (resilient over TCP); add confirmation messages; use Diffie-Hellman key exchange written to the BC for tamper-evident key negotiation [25][44]. Stopping Attack: Increase transaction pool size; disable node throttling; modify lockout configuration to allow any node to lead after mass failures and restarts [25]. Eclipse Attack: Ensure at least one honest node (raises attack cost to 51% attack level); use random peering; diversify connections geographically; maintain reputation-based trust scores; deploy monitoring with ML-based anomaly detection; maintain critical node backups [18][19][23]. Partitioning Attack: Add more BC nodes; allow concurrent multi-block downloads (minimum three sessions eliminate most partition vectors); migrate from TCP to QUIC [13][25]. Man-in-the-Middle: Deploy OAuth 2.0 with multi-factor authentication; issue digital certificates to all nodes via trusted providers (Amazon, Upvest, Kaleido); use public-private key encryption for all cross-chain messages [10][24][26]. C. Interoperability Countermeasures Relay Poisoning: Validate both block headers and transactions; require only one honest node to dispute invalid submissions; wait additional confirmation blocks before finalization to prevent chain reorganization [7][18]. Oracle Poisoning: Aggregate data from multiple independent sources and oracles; implement a dispute mechanism for oracle discrepancies; provide financial incentives for accurate reporting [18]. Goldfinger Attack: Apply merged-staking to protect new sidechains during bootstrapping; deploy monitoring with doublespending detection; reputation system to enforce proper behavior; limit mining pool size [1][23]. Sore Loser / Lockup Griefing: Add a premium payment as a penalty for abandonment (refundable on completion); implement a premium distribution phase in HTLC atomic swap protocols; shorten lock periods via immediate post-transaction unlock [1][28]. Unrestricted Deposit Emitting: Require verified lock events before any deposit is permitted; use only secure transfer functions; deploy automated pattern-matching detection tools [41]. Unauthorized Unlocking: Apply private key leakage protections; restrict unlock access to authorized cross-chain verification nodes only; deploy detection tools monitoring unlock transaction signatures [41]. D. Social Engineering Countermeasures Social Engineering: Enforce dual control for transactions; educate users on malware, suspicious links, communication tones, and unknown accounts; avoid contracts permitting address changes or string comparisons; deploy signature-based detection systems; build attack-tolerant systems with logging [35][36][37][38]. Phishing: Use browser anti-phishing extensions; train users to verify URLs, certificates, and email details; deploy URL and content detection algorithms; require two-factor authentication [23][33][35][36].
4
Homograph Deception: Educate users to verify full addresses and checksums; deploy automated monitoring for known attack patterns; ensure smart contracts include fallback functions; verify cross-contract function selectors via hex viewing [34][37]. E. Vulnerability Countermeasures Smart Contract Vulnerabilities: Follow secure development practices; conduct pre-deployment code reviews, strict testing, and formal modeling; avoid self-destruct functions; use vulnerability scanners; offer bug bounties; provide developer security education [1][6][15]. Public Key Cryptography: Use vetted libraries (e.g., mbedTLS); implement check values against fault attacks; generate keys with validated RNGs (XEdDSA, VXEdDSA); apply multisignature redundancy; enhance algorithm designs (Schnorr/DSA with re-keyed hash; ElGamal with Gaussian integers) [6][29][30][31][32]. Improper Value Validation: Enforce magic value and nonce validation for every cross-chain transaction [6]. Visibility Vulnerability: Explicitly label all functions and variables; audit access controls; encrypt sensitive data [6]. Weak Randomness: Replace insecure sources with secure RNG libraries designed for smart contracts (RANDAO, RBGC) [6]. Attack 51% Attack Sybil Attack Double-Spending Block Withholding Selfish Mining Fork After Withholding Private Key Leakage Nothing at Stake Time-Jacking Replay Attack Tx Malleability Reentrancy DoS / DDoS Botnet Packet-Dropping Stopping Attack Eclipse Attack Partitioning Man-in-the-Middle Relay Poisoning Oracle Poisoning Goldfinger Sore Loser / Lockup Unrest. Deposit Emit. Unauthorized Unlock Social Engineering Phishing Homograph Deception Smart Contract Vulns PK Crypto Vulns Improper Validation Visibility Vuln. Weak Randomness Tx Order Dependence Asset Counterfeiting Verifier's Dilemma Invalid Consensus Proofs Inconsistent Event Parse
Category BC BC BC BC BC BC BC BC BC BC BC BC Network Network Network Network Network Network Network Interop. Interop. Interop. Interop. Interop. Interop. Social Eng. Social Eng. Social Eng. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab. Vulnerab.
Transaction Order Dependence: Use a commit-reveal commitment scheme so solutions are hidden until processed, preventing front-running [6][3]. Asset Counterfeiting: Require collaterals with proof-of-balance checks; embed anti-counterfeiting rules in consensus; mandate distributed signatures for unknown-party transactions [15][18]. Verifier's Dilemma: Deploy a canary protocol that submits harmless invalid transactions to test vigilance; require nodes to stake on approvals, thereby incentivizing careful validation [39]. Invalid Consensus Proofs: Verify sync committee authenticity and block signatures; check block height to reject repeated proof submissions; apply DoS defenses to resist consensus proof flooding [15][40]. Inconsistent Event Parsing: Redesign parsers to include verification before any cross-chain asset issuance; deploy real-time detection tools to identify parsing attack signatures [15][41]. F. Summary Table II summarizes all countermeasures by attack and category.
Key Countermeasures Higher hash rate, more nodes, PoS validators, monitoring Permissioned BC, reputation system Hash rate, block validation, lock-and-burn, timestamps Monitoring, reputation, Stratum protocol, credit mechanism Block propagation opt., dynamic difficulty, timestamps Improved block confirmation, consensus enhancement Limit wallet funds, encrypt key, multi-sig transactions Checkpoint latch Tighter time restrictions, NTP, trusted peers Magic value & nonce validation, unique locks, timestamps Segregated Witness, strict sig encoding, validation Check-Effects-Interactions, mutex locks, audits More nodes, throttling, PoA consensus, monitoring Node authentication, user education, monitoring QUIC protocol, confirmation mechanism, DH key exchange Larger tx pool, disable throttling, lockout config Random peering, reputation system, diverse connections More nodes, concurrent downloads, QUIC protocol Authentication, digital certificates, encryption Header &tx validation, extra confirmations Multiple oracles/sources, dispute mechanism, incentives Merged-staking, monitoring, reputation system, limit mining pool size Premiums, HTLC premium phase, incentives Lock verification, secure transfer functions, detection Key protection, access controls, detection tool Dual control, user education, detection system Anti-phishing tools, user education, 2FA Checksum use, monitoring, verify selectors Best practices, testing, audits, formal modeling Secure library, check values, strong RNG, redundancy Validate magic values and nonces Label all functions/data, audit, encrypt data Secure RNG (RANDAO, RBGC) Commit-reveal scheme Collateral, consensus rules, distributed signatures Canary protocol, stake-based verification requirement Verify sync committee, block height checks Fix parser design, automated detection tool
Refs [12][16][19][23][42] [2][20] [17][23][27][35][42][43] [19][23] [19][23] [19][23] [11] [21] [23] [6][18][19][24][22] [19][23] [15][19] [11][17][23] [24][5] [25][44] [25] [18][19][23] [13][25] [10][24][26] [7][18] [18] [1][23] [1][28] [41] [41] [35][36][37][38] [23][33][35][36] [34][37] [1][6][15] [6][29-32] [6] [6] [6] [6][3] [15][18] [39] [15][40] [15][41]
TABLE II. ATTACK COUNTERMEASURES
5
V. CONCLUSION AND FUTURE WORK Effective BC interoperability requires comprehensive security from all threat vectors—not merely those specific to cross-chain protocols. BC attacks such as double-spending, replay, transaction malleability, and reentrancy can cause cross-chain fraud with asset loss. Network-layer attacks, including DoS and man-in-the-middle, can halt communication entirely. Interoperability-specific threats such as unrestricted deposit emitting, unauthorized unlocking, and relay/oracle poisoning can bypass bridge mechanisms entirely. Social engineering exploits the human layer even when technical security is strong. Finally, smart contract code and public key cryptography vulnerabilities can be exploited indefinitely once deployed. Several cross-cutting countermeasure patterns emerged: monitoring and detection systems address over 11 distinct threats; validation techniques prevent replay and consensus attacks; timestamp mechanisms defend against time-based attacks; reputation systems deter Sybil, eclipse, and Goldfinger attacks; and code audits prevent a wide range of smart contract vulnerabilities before deployment. However, security evolves continuously. Countermeasures must be combined into layered defenses capable of handling both known and novel threats. Privacy in BC interoperability—currently under-addressed—will be the focus of our subsequent work, followed by the development of enhanced architectural patterns for secure, attack-resistant BC interoperability bridges.
[24] L. Vishwakarma et al., "LBSV: Lightweight Blockchain Security Protocol," IEEE TVT, 2022. [25] A. Lebedev and V. Gramoli, "Blockchain Communication Vulnerabilities," 2026. [26] G. Lindemulder and M. Kosinski, "Man-in-the-Middle (MITM) Attack," IBM, 2024. [27] J. Kroll et al., "The Economics of Bitcoin Mining," FC Workshop, 2013. [28] Y. Xue and M. Herlihy, "Hedging Against Sore Loser Attacks," ACM PODC, 2021. [29] J.-M. Schmidt and M. Medwed, "A Fault Attack on ECDSA," FDTC, 2009. [30] Y. Romailler and S. Pelissier, "Practical Fault Attack against EdDSA," FDTC, 2017. [31] H. Morita et al., "On the Security of Schnorr Signatures," IEICE Trans., 2017. [32] R. Haraty et al., "Attacking ElGamal Using Pollard's rho," ACS/IEEE ICCSA, 2005. [33] A. A. Andryukhin, "Phishing Attacks and Preventions in Blockchain," IEEE EnT, 2019. [34] N. Ivanov and Q. Yan, "EthClipper: A Clipboard Meddling Attack," arXiv, 2021. [35] P. Weichbroth et al., "Security of Cryptocurrencies," Sensors, 2023. [36] A. Fakieh and A. Akremi, "Blockchain-Based Defense against Vishing," Appl. Sciences, 2022. [37] N. Ivanov et al., "Targeting the Weakest Link: Social Engineering in Ethereum SCs," ACM ASIACCS, 2021. [38] T. Li et al., "Defending against social engineering attacks," IET Inf. Sec., 2023. [39] P. Mccorry et al., "SoK: Validating Bridges as a Scaling Solution," arXiv, 2021. [40] X. Chang et al., "zkRouter: Trustless, General Cross-Chain Infrastructure," 2022. [41] J. Zhang et al., "Xscope: Hunting for Cross-Chain Bridge Attacks," ASE, 2022. [42] S.-S. Lee et al., "SoK: Review of Cross-Chain Bridge Hacks," arXiv, 2022. [43] E. Androulaki et al., "Evaluating User Privacy in Bitcoin," FC, 2013. [44] Y. Ren et al., "Traceable Key Negotiations via Blockchain for Vehicles," Hindawi, 2019.
REFERENCES [1] K. Ren et al., "Interoperability in Blockchain: A Survey," IEEE TKDE, vol. 35, no. 12, 2023. [2] S. Islam et al., "A Survey on Consensus Algorithms," IEEE Access, vol. 11, 2023. [3] S. Eskandari et al., "SoK: Front-running Attacks on Blockchain," FC Workshop, 2020. [4] H. Al-Safi et al., “Patient privacy in smart cities by blockchain technology and feature selection with Harris Hawks Optimization (HHO) algorithm and machine learning,” Multimedia Tools and Applications, vol. 81, no. 6, 2022. [5] Satya, "How to Defend Against Botnets," GeeksforGeeks, 2025. [6] N. Amiet, "Blockchain Vulnerabilities in Practice," Digital Threats, vol. 2, no. 2, 2021. [7] P. Frauenthaler et al., "ETH Relay: A Cost-efficient Relay," IEEE Blockchain, 2020. [8] L. Ismail and H. Materwala, "A Review of Blockchain Architecture," Symmetry, 2019. [9] L. Lys et al., "R-SWAP: Relay based atomic cross-chain swap," ALGOTEL, 2021. [10] G. Falazi et al., "Smart Contract Invocation Protocol (SCIP)," CAiSE, 2020. [11] E. J. Scheid et al., "Bifrost: a Modular Blockchain Interoperability API," IEEE LCN, 2019. [12] A. Thakur et al., "Scalability and Performance of Permissioned Blockchain," Cluster Computing, 2023. [13] H. Heo and S. Shin, "Behind Block Explorers," IEEE ICDCS, 2021. [14] R. Belchior et al., "A Brief History of Blockchain Interoperability," CACM, vol. 67, no. 10, 2024. [15] A. Augusto et al., "SoK: Security and Privacy of Blockchain Interoperability," IEEE S&P, 2024. [16] S. Soni and B. Bhushan, "A Comprehensive Survey on Blockchain," IEEE ICICICT, 2019. [17] S. Luca et al., "Security Analysis via Agent-based Simulation," Simulation, vol. 114, 2021. [18] A. Sanchez et al., "Bridging Sapling: Private Cross-Chain Transfers," IEEE Crosschain, 2022. [19] B. Ozdenizci Kose and A. Arik, "Blockchain Security: Emerging Threats," Blockchain Book, 2024. [20] Y. Wang and M. Tan, "Defense against sybil attack in blockchain," IEEE ICCECT, 2023. [21] G. Wood, "Polkadot: Vision for A Heterogeneous Multi-Chain Framework," 2019. [22] H. Chai et al., "CyberChain: Cybertwin Empowered Blockchain," IEEE TVT, 2022. [23] M. Conti et al., "A Survey on Security and Privacy Issues of Bitcoin," IEEE Comms Surveys, 2018.
6