Limitations of Existing Hack-Prevention Approaches

Last updated on June 17, 2024 · Jean-Loïc M.

Off-Chain Monitoring and Incident Response

The current dominant approach to Web3 security relies on off-chain monitoring and incident response. These systems aim to detect malicious transactions or contracts and prevent them from causing damage to the protocol. Common strategies include:

• Transaction and new-contract monitoring:
  • Scanning or simulating pending transactions in the mempool for suspicious patterns or behaviors, such as flash loans and mixer or bridge addresses.
  • Using artificial intelligence or heuristic analysis to detect potential attacks.

This approach shows clear limitations in scalability. Scanning every contract and running multiple heuristics to achieve limited certainty regarding transaction security is neither a reliable nor a scalable solution in the long run.

• Incident response:
  • Pausing the protocol — temporarily halting protocol activity when suspicious transactions are detected, allowing time for investigation.
  • Blacklisting addresses — preventing transactions from flagged addresses from interacting with the protocol.
  • Withdrawing funds — attempting to withdraw or secure protocol funds before malicious transactions can succeed.
  • Updating contracts — deploying new contract versions to mitigate vulnerabilities after an attack.

These objectives can only be achieved if projects act quickly and pay sufficient gas fees for their incident-response transactions to be executed before the malicious transaction. This relies entirely on timely execution. Even when achievable, these protocols may have significant operational impacts — preventing customers from interacting with them, causing panic, and reducing trust.

While these measures can mitigate damage in some cases, they are inherently reactive, lack reliability, transparency, and decentralization, and are vulnerable to being circumvented by skilled attackers.

The Malicious-Validator Scenario

The most challenging and resilient attack scenario occurs when a smart-contract attacker runs their own validator node. In this scenario:

1. The attacker deploys a malicious contract and creates a transaction that exploits the target protocol.
2. As a validator, the attacker includes both the contract deployment and the malicious transaction in the same block they validate, without sharing it with the network.
3. The malicious actions are only visible once the block is confirmed and propagated across the network.

This method bypasses all off-chain monitoring and response mechanisms because:

• Private transactions. The malicious transaction is never broadcast to other validators, evading detection.
• On-chain-only visibility. The exploit becomes apparent only after the block is confirmed and the damage is done.

No existing off-chain or reactive solution can prevent this type of scenario, as they rely on detecting malicious activity at stages the attacker circumvents entirely.

On-Chain Solutions: dApp Wrappers and Proxies

On-chain solutions such as dApp wrappers and proxies have been proposed to enhance security. However, these approaches are fundamentally limited due to the inner workings of the Ethereum Virtual Machine (EVM) and the nature of smart-contract interactions.

Smart contracts can be interacted with by both externally owned accounts (EOAs) and other smart contracts. The latter introduces a significant challenge: these interactions can include actions performed before and after interacting with the dApp. This lack of visibility makes it impossible for a dApp to determine whether it is the first or tenth interaction within a transaction, or if the interaction is part of a larger series of interactions within the same transaction.

This complexity becomes more critical when dApps rely on other smart contracts for data — decentralized exchanges, lending protocols, and other DeFi applications that depend on on-chain asset price calculations. Attackers can manipulate these price sources (oracles) to execute transactions with misleading or incorrect information.

For instance, flash loans allow attackers to temporarily borrow large amounts of capital to manipulate asset prices before a transaction interacts with a target dApp. Without visibility into these pre-interactions, the dApp cannot differentiate between genuine and manipulated data.

This issue has driven the adoption of centralized oracles and off-chain data feeds, which introduce their own trade-offs and compromise Ethereum's decentralization ethos. Price manipulation through oracles remains one of the most impactful attack vectors in DeFi, yet current on-chain solutions fail to address it effectively.

In conclusion, dApp wrappers and proxies lack the capability to address the core challenges of securing smart-contract interactions, leaving critical gaps in protection against complex attack vectors like flash-loan-driven price manipulation.