IPSProtocol

IPSProtocol is rewriting the industry narrative for hack prevention. Designed and conceived from scratch, it leverages current cybersecurity primitives to provide a reliable, scalable, decentralized, and transparent way to prevent hacks on-chain!

IPSProtocol modifies the blockchain’s role, specifically the execution engine and transaction execution flow. It introduces a new step in the post-transaction execution phase, positioned between the EVM transaction execution and the commitment of modifications to the blockchain. This process allows dapps, whose smart contracts are modified, to analyze the impact of transactions on their smart contracts before any changes are finalized. This provides dynamic and reliable hack prevention without relying on monitoring, unreliable frontrunning, or closed-source IAs.

A useful analogy is to think of transactions as cars navigating through a parking lot. Today, cars can move freely, even in forbidden areas, without any verification. IPSProtocol places a gate at the parking lot exit with guards managed by decentralized applications. IPSProtocol provides these guards with data about car behavior so they can determine whether the cars behaved safely. Only cars that took safe paths are allowed to exit, while those that violated rules are stopped. Similarly, transactions behaving badly are rejected and their changes reverted.

Our approach is groundbreaking as it changes the way we address hacks. Instead of worrying about numerous evolving attack vectors, which will continually change with new EIPs and smart contract composability, we focus on what dapps control: their software. We ensure their applications behave correctly from a functional perspective, as documented.

IPSProtocol creates a new type of smart contract called Firewall Contracts. These contracts protect other smart contracts by analyzing the changes a transaction produces. Firewall Contracts can revert transactions identified as malicious while allowing regular transactions to proceed.

To ensure reliable transaction impact analysis, IPSProtocol collects data compatible with the most reliable cybersecurity techniques, such as invariant/property-based testing used in fuzzing and formal verification. Our framework enables projects to dynamically analyze every single transaction using their fuzzing and formal verification tests.

IPSProtocol is the cornerstone for industrializing security in Web3. By significantly reducing the risk of hacks, it enables institutional investors and new products to emerge on public blockchains. This includes institutionalizing investment in DeFi and bringing real-world assets (RWA) to public blockchains, which have predominantly remained in permissioned/private blockchains.

IPSProtocol operates by modifying the blockchain execution client, go-ethereum, and its transaction execution flow.

IPSProtocol establishes a 1-to-1 relationship between firewall contracts and the specific contracts they protect. These firewall contracts receive all changes produced on their protected contract, without receiving data from other contracts, ensuring privacy and preventing censorship.

Firewall contracts are provided with three parameters to perform their invariant/property-based analysis:

• the address of a snapshot of the contract they are protecting at the start of the transaction (before tx changes)
• The address of the contract at the end of the transaction.
• All events and their parameters produced by the contract during the transaction.

To implement snapshotting of smart contracts, we developed a temporary state database (merkle tree) accessible from the EVM perspective. This database collects all contracts called during the transaction and filters only those that were modified. Unmodified contracts are not at risk of being hacked. This was one of the most complex tasks to implement.

Additionally, the dynamic tracer collects all events, a process previously impaired by the prestate tracer using diff mode. While the prestate tracer was used for tracing, it did not include event tracing, which we implemented at the opcode level.

Finally, managing the changes in the transaction execution flow and handling the reverts from firewall analysis only during the actual execution of the transaction (but not in the estimation) posed another interesting technical challenge.