Skip to main content

The Definitive Guide for Smart Contract Hack Prevention

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

Introduction​

Impact of Web3 Security Complexity on Decentralized Applications​

Building secure decentralized applications (dApps) has become one of the most significant challenges in the Web3 ecosystem. Security is always the top priority for protocols, as it is crucial to maintaining trust with both investors and users. Over 80% of dApp development timelines are consumed by security requirements, including:

  • Building Comprehensive Testing Strategies:

    • Rigorous internal testing campaigns, including unit testing and integration testing with the most common existing protocols. These tests often fail to account for potential integrations with new or unforeseen protocols, which may introduce insecure interactions because of permissionless composability.
    • Internal or external fuzzing campaigns are employed to identify potential vulnerabilities by testing whether certain conditions, known as invariants, remain true under various simulated interactions. These campaigns generate (semi-)randomized data to explore a wide range of application states and behaviors. While fuzzing is highly effective for uncovering bugs, it has inherent limitations: it is impossible to generate all potential states or interactions, highlighting its lack of completeness in covering every possible scenario.

  • Formal verification processes require highly specialized professionals to write precise specifications in mathematical form using dedicated programming languages. This adds significant cost and time to the development process. Similar to fuzzing, formal verification faces limitations in completeness: as applications grow in complexity and the state space to be explored expands, it can take years — or longer — to formally verify intricate protocols. Additionally, formal verification does not account for the complexity or potential manipulation of external dependencies, such as third-party contracts or oracles. While it is a valuable tool, these limitations make it an auxiliary approach rather than a comprehensive solution.

    While fuzzing and formal verification are effective for identifying vulnerabilities, neither approach ensures completeness regarding attack vectors and vulnerability detection and mitigation. Both methods can miss edge cases, as Web3 is a permissionless and composable environment where any smart contract behavior can be created and integrated into a protocol without prior approval. Additionally, the dynamic nature of the Web3 ecosystem introduces further complexity, as unforeseen market scenarios may emerge over time.

  • High Costs of Security:

    • Security audits often cost between six and seven figures, depending on the project's complexity.
    • Post-audit processes include short- and long-term bug bounty programs, which create ongoing expenses and dependencies on external players to assess every new protocol version.

  • Barriers to Innovation:

    • The high financial and operational barriers to launching a new protocol discourage smaller projects, contradicting the blockchain's decentralization ethos.
    • To minimize risks, many projects rely on well-established logic and practices, which can stifle creativity and slow down industry progress. For example, there are over 300 forks of Uniswap V2, each with more than $100,000 in Total Value Locked (TVL) across various blockchain ecosystems.

Despite these extensive efforts, the Web3 industry has lost over $60 billion to hacks and scams since 2017. This underscores the inadequacy of existing practices and the urgent need for robust, scalable, simple, and accessible security solutions.

IPSProtocol Firewall Client​

Overview​

The Firewall Client represents the long-term vision of IPSProtocol's hack-prevention solution. It introduces an additional blockchain client module at the infrastructure level, designed to provide robust and reliable hack-prevention capabilities. By integrating the Decentralized Firewall Engine, the Firewall Client ensures proactive, decentralized, automated, deterministic, and transparent hack prevention across the entire blockchain ecosystem.

Operating alongside the execution client, the Firewall Client plays a critical role in the transaction lifecycle at two key stages:

  1. Block Building: Validating transactions before they are included in a block, preventing malicious transactions from being added to the blockchain.
  2. Consensus: Ensuring that all nodes agree on the safety of block transactions, embedding hack prevention directly into the consensus process.

The Firewall Client does not detect malicious transactions independently. Instead, it provides a comprehensive and reliable framework — the Firewall Contract — that empowers dApps to dynamically analyze and secure their smart contracts from malicious transactions at runtime, mid-flight, before settlement. By leveraging this framework, dApps retain full ownership and control over their security mechanisms, allowing them to define, upgrade, and manage their detection logic transparently and autonomously.

This approach leverages the unique expertise of dApp developers, who best understand their protocols' intended behavior and specific security requirements. Firewall contracts adopt a plug-and-play design, allowing dApps that choose not to implement firewall clients to continue functioning normally, ensuring seamless and frictionless integration. IPSProtocol's solution provides an upgradable, decentralized, and scalable security mechanism, delivering reliable protection against hacks.

For node operators, the new architecture would look like this. Running the Firewall Client will enable node operators to access a new income stream.

L2 node architecture with Firewall Client

Decentralized Firewall​

The Decentralized Firewall is powered by IPSProtocol's custom IPS EVM, serving as the cornerstone of a cutting-edge hack-prevention framework. These components work together to process and analyze every transaction, extracting essential data. This data is then utilized by dApp firewall contracts to execute security tests, dynamically identifying and reverting non-compliant or malicious interactions in real time.

IPSProtocol Integration with Blockchain Protocols​

Integrating the firewall client with the execution client enables seamless communication, allowing the firewall to share the results of security tests. If malicious behavior is detected, the execution client can efficiently revert the transaction. This integration is designed to be straightforward and minimally intrusive, ensuring it does not significantly impact the execution client's logic.

  1. Parallel Execution of Firewall Contracts. Thanks to their independent design, Firewall Contracts operate in parallel. This allows their execution to run concurrently, with the only overhead being the time required for the longest-running contract. This design ensures optimal performance while maintaining robust security.

  2. Parallel Execution Between Execution Client and Firewall Client. When the Execution Client proposes a transaction (T1) for inclusion in a block, it proactively notifies the Firewall Client that the transaction is ready for processing. This early notification enables the Firewall Client to begin its operations promptly, reducing execution time discrepancies and ensuring seamless synchronization between the two components.

  3. Efficient Logic. Firewall Contracts implement simple yet effective security measures to prevent hacks. dApps are incentivized to keep their firewall code optimized to minimize execution costs.

Seamless Integration: A Simple Approach​

IPSProtocol and its Firewall Client seamlessly integrate with the transaction execution lifecycle by plugging into the State Transition Function (STF). This integration ensures that transactions undergo dynamic security checks without disrupting the blockchain's natural flow.

Transaction Workflow​

When block builders or validators build blocks and determine transaction order, they execute transactions as usual. However, before committing the resulting state changes to the blockchain, two outcomes are possible:

  1. Transaction is Safe:

    • The Firewall Client executes the transaction alongside the associated Firewall Contracts.
    • If no security rules are violated, the Firewall Client notifies the Execution Client to commit the transaction and its changes to the world state.

  2. Transaction is Non-Compliant:

    • If the Firewall Client detects a violation of a dApp's security rules (e.g., malicious behavior or non-compliance), the transaction is reverted.
    • The Firewall Client communicates the reason for non-compliance to the Execution Client, which then reverts the transaction and discards the state changes.

This approach ensures that all transactions are dynamically verified against dApp-defined security conditions before finalizing state transitions, preventing malicious or non-compliant activity from propagating on the blockchain.

The current transaction execution flow changes from:

Current transaction flow

to:

Transaction flow with the Firewall Client

Key Advantages​

  1. Decentralized and Scalable. The Firewall Client operates within the blockchain infrastructure, maintaining decentralization and preventing malicious nodes from bypassing the hack-prevention mechanism. In such cases, other nodes using the Firewall Client would flag and reject the block during consensus.

  2. Deterministic, Transparent, and Reproducible Security. Thanks to the execution of Firewall Contracts in the IPS EVM, IPSProtocol produces a deterministic, reproducible, and transparent security analysis process — preventing disguised censorship and increasing trust and explainability.

  3. Modularity. Different roles are handled by distinct and independent modules. The plug-and-play design of the Firewall Client minimizes its impact on existing clients and enables straightforward integration into the blockchain ecosystem. This modular approach also allows the Firewall Client to operate independently of the Execution Client, reducing the resources required for block proposers and simplifying node setup, maintenance, and operation.

  4. (Almost) Plug and Play. Integrating with the blockchain protocol requires minimal changes to the execution client, introducing fewer than three RPC API calls to the Firewall Client. The goal is to collaborate with blockchains to create a standard API for the Firewall Client so that all execution client implementations can easily integrate and seamlessly support Firewall Contracts.

  5. Plug and Play for dApps. dApps are not impacted by the addition of the Firewall Contract. Only dApps subscribing to the service and deploying their Firewall Contracts will benefit from the hack-prevention mechanism.

  6. New Income Stream. Hack prevention is offered as a service for dApps, requiring them to subscribe by depositing IPSTokens in the Deposit Contract. These tokens are then distributed to the block proposers responsible for conducting the security verifications.

  7. Block Building Independence. In the proposer-builder separation architecture for MEV, block builders might bypass the Firewall Client to prioritize performance, optimize MEV opportunities, or choose high-priority fees from malicious actors to include harmful transactions in blocks. However, the Firewall Client also participates in the consensus process together with the execution client and is therefore capable of detecting non-compliant transactions.

    As a result, validators detect the non-compliant nature of the block and choose not to attest it; the block is rejected by consensus. This directly impacts the block proposer's and builder's economics — they would not receive their rewards or the benefits from block building, making it financially disadvantageous not to use the Firewall Contract.

    Note: Block-building optimization is a critical activity, helping ensure market stability through arbitrage. However, this activity is predominantly controlled by a few centralized entities and operates largely off-chain, which conflicts with the principles of blockchain decentralization and transparency. IPSProtocol does not prevent MEV activities and has minimal impact on MEV profitability — hacks account for less than 1% of transactions — while also introducing a new source of income for block proposers and block builders.

    Furthermore, due to the financial incentives it provides, dApps and blockchain ecosystems will be empowered to enforce more compliant block-building practices. This ensures that the rules and principles defined by dApps and the ecosystem are respected, shifting power back to the blockchain network and reinforcing the ethos of decentralization.

Addressing Firewall Client Execution Time Overhead​

To provide the Firewall Contracts with relevant data for their security tests, the Firewall Client needs to execute the entire transaction similarly to the Execution Client and subsequently execute the Firewall Contracts.

A common question that arises is the impact of the Firewall Client's execution time on the block-processing step. This challenge is mitigated by optimizing the transaction forwarding and ordering process between the Execution Client and the Firewall Client, enabling the Firewall Client to start as early as possible. If the transaction order is provided sufficiently in advance, the Firewall Client can complete its execution and expose the results asynchronously for the Execution Client to collect.

  1. Firewall Contract Parallel Execution. Thanks to the Firewall Contract architecture, multiple Firewall Contracts can be executed in parallel, ensuring minimal overhead.

  2. Optimized Firewall Integration. The Firewall Client is designed to receive transaction order and pre-confirmed transactions as early as possible, directly from sequencers or block builders. This proactive notification allows the Firewall Client to prepare in advance, minimizing any potential latency during block creation.

  3. Specialized Design. The Firewall Client functions as a specialized module, optimized for high performance and reliability. Regular profiling and performance-monitoring campaigns are conducted to identify and resolve bottlenecks.

  4. Horizontal Scalability. The modular architecture of the Firewall Client enables horizontal scaling, allowing it to span multiple instances to parallelize independent transaction execution when possible — for example, transaction execution in a sharding architecture or parallel execution. By distributing workloads across instances, the Firewall Client can parallelize transaction execution and maintain consistent performance even in blockchain ecosystems with varying throughput.

By addressing execution time overhead through these strategies, the Firewall Client integrates seamlessly within the blockchain client architecture, delivering robust security for smart contracts without compromising performance.

Firewall Contracts​

Definition and Purpose​

Firewall Contracts (FCs) are a new type of smart contract specifically designed for hack prevention through the implementation of advanced security tests. Firewall Contracts are deployed on-chain, ensuring decentralization, transparency, reproducibility, and explainability as they are executed in the EVM.

These contracts serve as essential security tools for dApps, enabling them to define and enforce the intended behaviors of their protocols. FCs are built on a unique architecture and are dynamically supplied with specialized data generated by the business logic smart contract. Such data allow for comprehensive security analysis. The technical details of this architecture are addressed later.

Similar to other smart contracts, dApps retain full flexibility to implement custom logic within Firewall Contracts to analyze the impact of transactions on their contracts. It is crucial to understand the relationship between Firewall Contracts and business logic smart contracts: each Firewall Contract is associated with only one specific business logic smart contract.

Firewall Contracts are executed within the EVM, inheriting all the capabilities of standard smart contracts, including full access to accounts and the global state.

Key Features​

  1. Proactive and Decentralized Hack Prevention. Enforces security rules for every transaction at the blockchain protocol level, preventing malicious actors from bypassing these mechanisms. Enhanced transaction visibility utilizes data from the Decentralized Firewall and IPS EVM to provide dApps with detailed insights into transaction activity.

  2. Splitting Business and Security Logic. Firewall contracts allow dApps to remove part of the security logic from the business logic contract, simplifying business logic code and parallelizing development. Devs focus on functionality while security engineers focus on the security logic. Separate logic also allows firewall contract upgradeability without impacting the business logic contract — reducing operational complexity considerably when publishing fixes.

  3. One-to-One Mapping. Each Firewall Contract is directly linked to a single business logic smart contract, ensuring precise and unambiguous security coverage.

  4. Upgradeable Security Logic. Each Firewall Contract is directly linked to a single business logic smart contract; the mapping is done on-chain. If a problem is detected in the firewall contract, it is possible to deploy a new version and update the mapping. This also enables alpha testing strategies and better access control to features in the protocol. The upgradeability process should be carefully designed to ensure a safe transition.

  5. Frictionless Integration. dApps require no modifications to their existing codebases. To benefit from hack prevention, deploy a firewall contract and subscribe to the service. dApps that do not declare firewall contracts continue to be executed normally.

  6. Censorship Protection. Firewall Contracts only receive data related to the smart contract they protect. No dApp can use data external to its protocol in its analysis — preventing eventual censorship (for example, reverting a transaction if it includes an interaction with a competitor).

  7. Transparency. Firewall Contracts operate on-chain with fully transparent logic to ensure deterministic results and improve trust.

Addressing Transparency Concerns​

A common question arises: does storing Firewall Contract rules on-chain make it easier for hackers to understand and circumvent protections?

The answer is no. IPSProtocol's Firewall Contracts employ behavior-based security tests and invariants focused on enforcing intended application behavior. This ensures that even if the rules are visible, they remain highly effective in detecting and preventing malicious transactions. Attackers cannot bypass the logic governing normal protocol behavior.

Service Model​

Overview​

The node operator running a validator or sequencer will also run the Firewall Client. Hack-prevention tests are executed by the node and are triggered by payments from dApps. Similar to transaction execution, these tests require gas-token payments for security.

Payments are made using the infrastructure token, creating consistent demand for the token. dApps seeking hack-prevention services must purchase and deposit tokens in the Firewall Deposit Contract on Ethereum mainnet. This process parallels how Ethereum validators stake ETH to participate in network consensus.

Node operators running the Firewall Client will be paid in gas tokens, while IPSProtocol receives a portion of the revenue for maintaining and improving the service. Additionally, a portion of the revenue is allocated to the Protocol Guild, funding research and development in the Ethereum ecosystem.

Service Access​

Gas tokens are essential for compensating node operators and supporting IPSProtocol's ongoing development of the Firewall Client and adjacent security solutions. dApps are responsible for paying for the service via the Deposit Contract.

  1. Prepayment.

    • dApps deposit gas tokens into the IPSProtocol Deposit Contract to prepay for the hack-prevention solution.
    • Hack prevention is applied to every transaction.
    • dApps are responsible for recharging their accounts to ensure uninterrupted service and fair compensation for all participants.

  2. Subscription (Future Development).

    • In the medium to long term, alternative payment models like subscriptions may be introduced.
    • These models aim to provide flexibility and ease of use for dApps, catering to varying security needs and levels of hack prevention services.

Key Benefits​

  1. Mitigating Denial of Service (DoS) Risks. Running code in a permissionless environment introduces risks of DoS attacks on nodes executing EVM code. Similar to Ethereum's gas-fee model, IPSProtocol uses gas fees to prevent service disruptions caused by malicious or excessive usage. Tokens are also used to compensate nodes for executing security tests for dApps.

  2. Increasing Token Demand. The service creates a natural and recurring demand for gas tokens within the ecosystem. Beyond end-users acquiring tokens for transactions, dApps generate constant demand to utilize hack-prevention services. This fosters a virtuous growth cycle, where increased dApp usage drives token acquisition, strengthening the ecosystem and enhancing security.

Deposit Contract Security​

The IPSProtocol Deposit Contract, deployed on mainnet, integrates mechanisms to ensure both functionality and security:

  • Securing dApp Balances. The contract securely holds gas-token balances deposited by dApps, ensuring the execution of their Firewall Contracts.
  • Mapping Mechanisms. Maintains a mapping between dApps' smart contracts and their respective Firewall Contracts.
  • Controlled Balance Updates. Only Firewall Clients can update balances in the Deposit Contract, and this is done after providing proof of execution, which is verified by the deposit contract logic. This process is similar to how validators update the validator deposit contract on Ethereum mainnet. The Firewall Client and the Firewall Network manage updates to the Firewall Deposit Contract after the Firewall Layer reaches consensus.

By combining secure deposit and setup mechanisms with a blockchain-agnostic design, IPSProtocol delivers a scalable, reliable, and accessible hack-prevention solution for the entire Web3 ecosystem.

Firewall Layer​

Over time, as IPSProtocol's hack-prevention approach proves to be the simplest, most reliable, and decentralized solution, it aligns with Ethereum's vision of modularity: distinct layers responsible for different blockchain functionalities. IPSProtocol envisions a decentralized network of node operators dedicated to hack prevention and transaction compliance, forming a new Firewall Layer.

Similar to Ethereum's current architecture — where the Execution Layer (EL) and Consensus Layer (CL) are evolving into two independent blockchain networks with distinct databases and roles — the Firewall Layer extends this modular framework. It introduces a logical architecture designed to integrate into an ecosystem where decentralization is critical.

Even if Ethereum mainnet transitions fully into a settlement layer, infrastructure management increasingly relies on smart-contract-triggered actions between the EL and the CL. With new implementations such as EOF (Ethereum Object Format) or Account Abstraction, ensuring the secure execution of services foundational to all blockchain layers, DeFi, and other ecosystem verticals remains critical.

Firewall Blockchain​

The Firewall Layer maintains its own blockchain-based database, much like the EL and CL. While Firewall Clients operating in the IPS EVM detect malicious hacks, most account states still reside on mainnet. A forked state database suffices to execute the hack-prevention logic while managing both blockchain databases.

In the Firewall Blockchain, the following are stored:

  1. Firewall Contracts State.

    • Firewall contracts executed in the IPS EVM cannot alter their state in the Execution Client. However, maintaining a copy of their state on the Firewall Blockchain allows seamless operation, and dApps can run stateful invariants.
    • With proper logic, execution can dynamically switch between the EL database and the Firewall Layer (FL) database within the IPS EVM.

  2. Deposit Contracts State.

    • Deposit contracts are deployed on the world state and:
      • Map dApps' business logic smart contracts to their associated firewall contracts.
      • Maintain balances for dApp firewall client operators and IPSProtocol.
    • Since only firewall clients track the gas consumed by dApps, it is essential to update these balances within the Firewall Blockchain database.

Settlement and Synchronization​

Once per week or month, the Firewall Client Network issues cryptographic proofs for all executed operations to the Deposit Contract on mainnet. This ensures transparency and accountability by:

  • Validating all actions performed by the Firewall Layer.
  • Moving gas tokens deposited by dApps to their intended beneficiaries that provided the service.

This mechanism mirrors the existing functionality of the Consensus Layer, which allows validators to withdraw funds or face slashing penalties for malicious behavior. By adopting this model, the Firewall Layer integrates seamlessly with Ethereum's modular ecosystem while maintaining the highest levels of security and reliability.

Last updated on by Jean-Loïc M.