## 3 Security Threats
### Layer-Based Attack Classification
\begin{table}
\begin{tabular}{l l l l} \hline
**Attack Name** & **Layer** & **Impact** & **Counter Measure** \\ \hline Vector 76 & Consensus & Double spending, Loss of trust & Multiple confirmation, Improved consensus. \\ \hline Selfish Mining & Consensus & Mining pool, Double spending, and centralization. & Fork resolution scheme, Rational mining scheme. \\ \hline Block Withholding & Consensus & Disruption of consensus, Centralization, Reduced transaction speed. & Zeroblock algorithm, Pool incentives. \\ \hline Bribery & Consensus & Integrity, Reduced confidence, Trust Pool. & Improved consensus such as PoS and strong incentives. \\ \hline Re-entrancy & Contract & Wallet theft, Disruption of application. & Security Audits, Secure coding practices, Checks-effects-interactions (CEI) pattern. \\ \hline Integer Overflow & Contract & Unintended token transfer, DoS, Smart contract failure. & Careful smart contract design, Symbolic execution for detection. \\ \hline Short Address & Contract & Validation error & Automatic sanitization techniques. \\ \hline Balance & Contract & Double Spending, Reduced Network Efficiency. & Fast block confirmation, Monitoring. \\ \hline Cryptojacking & Application & Performance degradation, Increased operational cost. & Detection software, Network monitoring. \\ \hline Cold wallet & Application & Loss of funds. & Careful Smart Contract design, Multifactor authentication. \\ \hline Hot wallet & Application & Loss of funds and trust. & Regular software upgrade, Multifactor authentication. \\ \hline Dictionary & Application & Private key compromise, Unauthorized access and control. & Strong password, Hardware wallet. \\ \hline Malware & Application & Private key compromise, Network integrity. & Usage of antimalware or detection software. \\ \hline \end{tabular}
\end{table} 
Table 2: _Cont._ \begin{table}
\begin{tabular}{l l l l} \hline
**Architecture** & **Applies** & **Adjustments** & **Remarks** \\ \hline Chain-based (Bitcoin, Ethereum) & Yes & No & Fully compatible with all five layers. \\ \hline DAG-based (IOTA [38], Hedera) & Yes & Minor & Non-linear consensus, but threats map to Network \& Consensus layers. \\ \hline Hybrid (Hyperledger Fabric [39]) & Yes & Yes & No token layer; chaincode maps to Contract. Rename Consensus \& Incentive. \\ \hline Sharded (Ethereum 2.0 [40]) & Yes & Yes & Cross-shard comm. affects Network/ Consensus layers. \\ \hline BFT-based (Cosmos, Tendermint [41]) & Yes & Minor & Consensus layer must model validator-specific attacks. \\ \hline \end{tabular}
\end{table} 
Table 3: Applicability of layer-based taxonomy to blockchain architectures. The core architectural concepts--data persistence, peer communication, consensus coordination, contract logic, and user-facing applications--are present in all these systems, albeit with architectural nuances. DAGs remove block serialization but retain vulnerabilities across the network and consensus layers. Hyperledger lacks incentive mechanisms but retains contract-level logic via chaincode. Sharded platforms require coordinated consensus across shards and routing mechanisms, while BFT-based protocols must address equivocation and round-skipping attacks. Despite these differences, the five-layer taxonomy remains applicable with only minor adjustments to consensus or contract layers, validating its utility across diverse decentralized architectures.